Securing LLMs with Bedrock Guardrails for PII

11 Nov 2025 Securing LLMs with Bedrock Guardrails for PII

As organisations continue adopting generative AI, one question consistently surfaces: how do we keep sensitive data safe when models learn from natural language?

This post explores how personally identifiable information (PII) behaves in a GenAI world, why traditional data-protection methods fall short, and how Amazon Bedrock Guardrails offers a practical path forward for Australian organisations with strict privacy and data-residency requirements.

Readers should have a general understanding of key concepts such as personally identifiable information (PII), large language models (LLMs) and generative AI services like Amazon Bedrock. Building on that foundation, we’ll explore how PII risks have evolved in the age of AI and what that means for data protection practices.

What is PII in the age of GenAI?

According to the OAIC, PII refers to information that can reasonably identify an individual, along with contextual details that can be combined to reveal identity. For instance, a model might not directly expose a person’s name but could expose job title, suburb, and company that together are strong clues. Traditional Data Loss Prevention (DLP) tools were built to address data-at-rest (scanning a database) and data-in-transit (scanning email egress), but were not designed to handle the real-time, bidirectional flow of data inside a model’s API. This real-time, conversational risk surface creates a compliance gap that Guardrails is purpose-built to fill.

What are Guardrails and why they matter

Amazon Bedrock Guardrails inspect input prompts and model responses for policy violations, PII, or unsafe content. Guardrails let you define specific conditions (regex matches, banned terms or entity types) and specify actions (mask, block, or flag). What makes Guardrails powerful isn’t the filtering itself; it’s where that filtering happens. Instead of relying on external firewalls or post-processing scripts, Guardrails acts within the model’s workflow, allowing privacy controls to happen at inference time.

Moreover, Guardrails can work across any foundation model, inside or outside of Bedrock. Using automated reasoning, it helps reduce hallucination via contextual grounding, filters harmful or unsafe content, provides fine-grained control to tailor protections to use cases, and allows PII to be filtered or masked.

Beyond the technical layer, Guardrails directly addresses one of the biggest blockers to GenAI adoption: trust. Around 60% of enterprise AI initiatives stall before production due to data privacy and governance concerns. Without safeguards like Guardrails, those issues are often discovered only after the damage is done, either in audit logs or user complaints. Embedding controls at the model layer intercepts risks before output reaches production, shifting governance from reactive oversight to proactive assurance that’s measurable in real-time.

Configuring Guardrails for the Australian Context

Whilst Bedrock Guardrails is a powerful safety and privacy control tool, it’s not flawless out of the box. Australia’s current Proposals Paper on Mandatory Guardrails for AI in High-Risk Settings reinforces that voluntary privacy controls are no longer sufficient. It advocates for mandatory, risk-based guardrails to be embedded into AI systems that process personal or sensitive information. Bedrock Guardrails aligns closely with this direction by offering a configurable, preventative layer that helps organisations operationalise testing, transparency, and accountability principles before legislation makes them mandatory.

However, to implement these controls effectively, Australian users should be aware of some region-specific limitations and configuration needs. Two are worth calling out:

Compliance & Latency

Guardrails is available in Sydney, but some advanced features (such as automated reasoning checks) are still hosted in specific global regions. When these are invoked, the request payload may temporarily traverse outside Australian infrastructure, introducing latency as well as potential cross-region data handling.

For organisations regulated under the Australian Privacy Act or APRA standards, this distinction matters. Under APP 8 on cross-border disclosure, entities must ensure that any personal information leaving Australian jurisdiction remains protected by equivalent safeguards. To maintain compliance, teams should:

• Confirm local processing: Identify which Guardrail features run in ap-southeast-2 (Sydney) and which rely on other regions.
• Review AWS documentation on cross-region support.
• Avoid global routing: Do not route workloads containing sensitive PII to global model endpoints unless contractual and encryption controls are in place.

Local PII formats

The default filters don’t always recognise Australia-specific identifiers (like TFNs, Medicare numbers, or state driver’s licence formats). Custom regex or entity rules will need to be added for full compliance. These localisation gaps can be mitigated by configuring custom Guardrail rules that can detect Australian-specific formats and mask them automatically.

To put this into practice, we’ve configured a simple example to show how Guardrails can detect and mask Australian Tax File Numbers (TFNs) in real time.

Demo – Custom Regex for TFNs

In Australia, a TFN is a nine-digit numeric identifier issued by the Australian Tax Office (ATO), which can be written with or without spaces. (e.g. 123 456 789 or 123456789). Below is the Bedrock console view of the rule configuration in a sensitive information filter. In the ‘Regex’ section, we’ve added the TFN pattern and set the action to mask for both input and output, ensuring the Guardrail intervenes before sensitive data reaches the model.

Once the guardrail is created, we can test it directly in the Bedrock console. When the input prompt contained a TFN, the Guardrail intervened and replaced it with a masked label Australian TFN. We can confirm in the trace panel that the regex rule was triggered and applied.

This example shows how custom Guardrails can be configured to automatically detect and mask sensitive identifiers, preventing Australian-specific PII from appearing in prompts or model responses. It highlights how privacy protections can operate within the model workflow rather than relying solely on external sanitisation or post-processing tools.

Below are other regex patterns for common Australian Identifiers that can be added directly into a Guardrail configuration:

• Medicare Number: \b[2-6]\d{3}\s?\d{5}\s?\d\b
• Australian Business Number (ABN): \b\d{2}\s?\d{3}\s?\d{3}\s?\d{3}\b
• Australian Driver’s Licence (NSW): \b[A-Z0-9]{6,8}\b
• Australian Driver’s Licence (VIC): \b\d{9,10}\b
• Tax File Number (TFN): \b\d{3}\s?\d{3}\s?\d{3}\b

Note: These patterns are a starting point for common formats. Patterns for generic formats, such as driver’s licences, may require tuning in production to avoid a high rate of false positives.

Where to start with Guardrails

If you’re ready to implement Guardrails in your environment, here’s a simple starting framework:

1. Start in ‘flag’ mode: Begin in a dev/staging environment to test your regex and entity rules. Once validated, deploy Guardrails in production with flag-only actions for the first release cycle. This lets you observe how and where PII appears in real prompts and responses before enforcing any blocks.
2. Collaborate with compliance: Work with your legal and governance teams to build a shared library of Australian identifiers and regex rules.
3. Mask before you block: Masking keeps workflows smooth while securing sensitive data. Reserve hard blocks for higher-risk use cases.
4. Test and monitor: Review Guardrail trace logs and model responses regularly to fine-tune accuracy and reduce false positives.
5. Evolve continuously: Update rules as identifier formats change and as you add new model endpoints.
6. Educate your users: Inform your teams about what is being masked or blocked and why. This prevents confusion and helps them write more effective, compliant prompts.

Beyond Regex: A Layered Defence

Regex-based detection works well for structured identifiers, but it can’t capture the full spectrum of risk that generative AI introduces. As mentioned above, sensitive information isn’t always a number or a name; it can appear as fragments of context that, when combined, reveal who someone is. For instance, a model might output “the senior nurse at a private oncology clinic in Parramatta”, which could clearly identify a particular individual even without explicit PII.

Guardrails should be seen as part of a broader compliance framework, not the whole solution. They mitigate exposure in real time, but a fully compliant GenAI workflow also requires:

• Pre-processing filters to anonymise or redact sensitive data before prompt injection.
• Entity-level detection through tools such as Amazon Comprehend’s PII detection for unstructured text.
• Data-at-rest governance using services like Amazon Macie to monitor and classify stored data.
• Ongoing audit and human oversight to validate model outputs in high-risk or customer-facing use cases.

This layered approach ensures privacy protection at every stage of the model lifecycle: before data enters, while it’s processed, and after it leaves the model. Guardrails is a vital enforcement layer, but compliance is achieved only when it’s embedded into the broader governance fabric of how AI systems are built and maintained.

Looking Ahead

As AI becomes embedded in everyday systems, our understanding of PII must evolve. What counts as personal today will soon evolve to include patterns of language, tone and behaviour that uniquely identify us in ways regulation hasn’t yet caught up with.

For security and compliance teams, that means shifting from protecting known identifiers to safeguarding emerging identities. Tools like Bedrock Guardrails mark the start of that transition, moving privacy controls from after-the-fact detection to real-time reasoning inside the model pipeline.

The next frontier of privacy demands we design systems that forget with as much intent as they learn, recognising potential sensitivity before we’re forced to define it.