Mapping DTA's New AI Rules to AWS Bedrock Guardrails

I'm designing a Bedrock-backed application on top of lex-au-search, a public semantic search over Commonwealth legislation. The application answers practitioner questions that touch sensitive personal information: tax file numbers, estate details, Centrelink eligibility. Before writing any code, I wanted to know exactly what the Digital Transformation Agency's new agentic AI rules require, and exactly which Bedrock setting satisfies which requirement.

That mapping didn't exist anywhere I could find, so I built it myself. This post documents the mapping and the results of my testing. Every JSON block is output from Bedrock guardrail experiments I ran in Sydney (ap-southeast-2).

Quick terminology clarification before we start. Australia also has a voluntary AI Safety Standard with ten governance guardrails, published by the Department of Industry, Science and Resources. "Bedrock Guardrails" is AWS's runtime content safety API. When this post says "guardrail", it means the AWS product.

What the DTA actually asks for

The DTA's updated AI policy made an internal register of in-scope AI use cases mandatory from 15 June 2026. The AI Impact Assessment requirement, which agencies must complete for every in-scope use case (agentic systems included) before deployment, follows on 15 December 2026. The agentic AI addendum itself sits alongside this policy as best-practice technical guidance and doesn't carry a separate compliance date of its own.

The addendum defines three human oversight modes:

• HITL (human-in-the-loop): a person signs off before anything high-stakes or irreversible happens, like an entitlement decision or a payment.
• HOTL (human-on-the-loop): a person watches continuously and can pause or override.
• HOOTL (human-out-of-the-loop): fully autonomous, with periodic audits and post-action sampling rather than a human in the decision path.

Worth knowing if you're picking a mode: Criterion AGT.1.2 in the addendum is a binding "must", and it only names two of the three: "Oversight must be maintained through a human-in-the-loop or human-on-the-loop governance model." HOOTL is defined as a mode elsewhere in the document, but it isn't one the binding criterion accepts as a primary oversight model.

For my tool, where the AI produces advice and a human practitioner acts on it, HOTL is the right mode, and it satisfies AGT.1.2. The agent never submits data or applications to any government agency; the practitioner does.

Interested in HOTL? My Agent Tower blog post walks through an example HOTL interface: a Notion kanban board as the human-oversight cockpit for a running agent pipeline. Its "Steer" pattern (agent posts findings, waits on a timeout for an operator note, auto-advances if none) is a HOTL-style watch-and-override loop; the post also covers a stricter "Gate" pattern for mandatory sign-off, closer to HITL.

Past oversight mode, the addendum's lifecycle stages point to (paraphrased from the full PDF, not a verbatim requirements list):

• Audit trails and observability: "logs, metrics, and audit trails" to detect issues and support governance, in the addendum's own words
• Data minimisation and sensitive-information exposure limits across memory and multi-step workflows
• Controls against injection attacks, named directly under the Integrate stage (typed interfaces, input/output validation)
• Continuous monitoring for drift and anomalies, under the Monitor stage
• Rollback and kill-switch mechanisms, under the Decommission stage
• Controlled, accountable deployment rather than "uncontrolled or inconsistent deployments... across the organisation"

Bedrock Guardrails handles four of those out of the box. The other two live at the application layer, outside anything AWS provides.

The mapping

Here's the short version. Details on each row (including what broke, what surprised me, and the real API output) are in the collapsible sections underneath.

PII protection

In plain terms: strip tax file numbers, Medicare numbers, names and addresses out of anything going in or coming out of the model.

"action": "GUARDRAIL_INTERVENED",
"assessments": [{
  "sensitiveInformationPolicy": {
    "regexes": [{
      "name": "AUSTRALIAN_TAX_FILE_NUMBER",
      "match": "123456789",
      "action": "BLOCKED",
      "detected": true
    }]
  }
}],
"outputs": [{"text": "This request has been blocked by content safety guardrails."}]

"action": "GUARDRAIL_INTERVENED",
"assessments": [{
  "sensitiveInformationPolicy": {
    "regexes": [{"name": "AUSTRALIAN_TAX_FILE_NUMBER", "match": "123456789", "action": "BLOCKED", "detected": true}]
  }
}],
"outputs": [{"text": "This response has been blocked by content safety guardrails."}]

"action": "GUARDRAIL_INTERVENED",
"assessments": [{
  "sensitiveInformationPolicy": {
    "regexes": [{"name": "AUSTRALIAN_TAX_FILE_NUMBER", "match": "123456789", "action": "ANONYMIZED", "detected": true}]
  }
}],
"outputs": [{"text": "My client's TFN is {AUSTRALIAN_TAX_FILE_NUMBER}"}]

Prompt injection controls

The DTA addendum names this directly as "injection attacks" under its Integrate stage: block attempts to hijack the model with injected instructions. The addendum's own treatment is one line (typed interfaces, input/output validation); it lists ASD's guidance on securing agentic AI as a related standard for the implementation depth it doesn't cover itself.

"action": "GUARDRAIL_INTERVENED",
"assessments": [{
  "contentPolicy": {
    "filters": [{"type": "PROMPT_ATTACK", "confidence": "HIGH", "filterStrength": "HIGH", "action": "BLOCKED", "detected": true}]
  }
}]

"action": "GUARDRAIL_INTERVENED",
"assessments": [{
  "contentPolicy": {
    "filters": [{"type": "PROMPT_ATTACK", "confidence": "HIGH", "filterStrength": "HIGH", "action": "BLOCKED", "detected": true}]
  },
  "topicPolicy": {
    "topics": [{"name": "ndis-eligibility", "type": "DENY", "action": "BLOCKED", "detected": true}]
  }
}]

Audit trail

Record what the guardrail did, every time it did it.

{
  "timestamp": "2026-08-09T03:44:33Z",
  "accountId": "100255142829",
  "region": "ap-southeast-2",
  "operation": "Converse",
  "modelId": "anthropic.claude-3-haiku-20240307-v1:0",
  "input": {
    "inputBodyJson": {"messages": [{"role": "user", "content": [{"text": "My client's TFN is 123456789"}]}]}
  },
  "output": {
    "outputBodyJson": {
      "output": {"message": {"role": "assistant", "content": [{"text": "This request has been blocked by content safety guardrails."}]}},
      "stopReason": "guardrail_intervened",
      "trace": {"guardrail": {"inputAssessment": {"nfg0qngueikh": {"sensitiveInformationPolicy": {"regexes": [
        {"name": "AUSTRALIAN_TAX_FILE_NUMBER", "match": "123456789", "action": "BLOCKED", "detected": true}
      ]}}}}}
    }
  }
}

Anomaly detection

The addendum's Monitor stage calls for detecting drift and anomalies. What Bedrock ships is a starting point, not the full thing.

Worth configuring even though the DTA doesn't name them

Two more controls address risks specific to my use case. They're not mandated by the addendum, but they're the kind of thing you'd want documented in an AI Impact Assessment anyway.

Denied topics

Blocks out-of-scope advice: state probate law, NDIS eligibility, active Centrelink account queries.

Grounding check

Flags responses that aren't grounded in the retrieved legislation.

Want claim-level grounding instead of one pass/fail score? My Grounding Inspector blog post describes how you can decompose a response into individual claims and check each one against the source document separately, rather than a single grounding score for the whole response. Same underlying question (is this grounded in the source?), a finer-grained answer.

// Correct answer
"contextualGroundingPolicy": {"filters": [
  {"type": "GROUNDING", "threshold": 0.7, "score": 1.0, "action": "NONE", "detected": false},
  {"type": "RELEVANCE", "threshold": 0.7, "score": 1.0, "action": "NONE", "detected": false}
]}
// Fabricated figure
"contextualGroundingPolicy": {"filters": [
  {"type": "GROUNDING", "threshold": 0.7, "score": 0.0, "action": "BLOCKED", "detected": true},
  {"type": "RELEVANCE", "threshold": 0.7, "score": 0.02, "action": "BLOCKED", "detected": true}
]}

On tier choice. Bedrock Guardrails has a Standard tier for prompt-attack detection that adds prompt-leakage as a third sub-type, beyond jailbreaks and injections. To get it, AWS requires that you explicitly opt in to cross-Region inference, meaning your request might get processed outside ap-southeast-2. That directly conflicts with the reason this whole architecture is pinned to Sydney in the first place: APS data sovereignty. Everything in this post uses Classic tier, which stays fully regional. If your workload genuinely needs data residency, check tier availability and inference routing before flipping Standard on. It's not a trade-off the console makes obvious.

On which API to call. AWS shipped InvokeGuardrailChecks in June 2026, a resourceless API that runs individual safeguards on demand and returns numeric scores without blocking anything. Handy for quick exploration. For the APS compliance case I used ApplyGuardrail and Converse with a versioned guardrail resource instead, for two reasons: a resource-based guardrail gets a stable ARN that shows up in CloudTrail, and it actually blocks rather than just scoring. InvokeGuardrailChecks is detect-only. It can't satisfy the DTA's audit trail requirement by itself.

Controlling what the agent can do, not just what it can say

Guardrails filters what the model says. It has nothing to say about what the model is allowed to do, which tools it can call and under what conditions. The addendum requires least-privilege tool access, which maps to a different service entirely.

AgentCore Policy (GA 3 March 2026, Guardrails support added 17 June 2026) runs on Cedar under the hood: you write policies in natural language and AWS converts them to Cedar, its open-source policy language. Enforcement happens at the AgentCore Gateway boundary, before a tool call completes.

One scope limit worth knowing about: AWS documents that Policy evaluation applies only to MCP tools routed through the AgentCore Gateway. It doesn't intercept direct Bedrock Knowledge Base queries or SDK calls that bypass the Gateway (Knowledge Base access routed through the Gateway as a target type is covered; direct access isn't). If your architecture is a hybrid of Gateway-routed tools and direct Knowledge Base access, that's partial least-privilege coverage, not full.

For my application, this is what restricts search queries to Acts in scope and denies calls to legislation outside scope. Put together, the layers are:

• AgentCore Policy: what the agent can do
• Bedrock Guardrails: what the agent can say
• CloudWatch: evidence of both

What none of this covers

Three things stay open at the infrastructure layer no matter how the above is configured.

Corpus poisoning. A compromised source document, a scraped third-party page or a superseded Act with malicious text inserted, can carry instructions that execute when it's retrieved. Testing above showed PROMPT_ATTACK does catch an obvious injection phrase even sitting in an untagged block, but Guardrails is still a runtime content filter. It evaluates whatever text arrives at the API boundary and has no visibility into where that text came from. A more subtle injection than "IGNORE PREVIOUS INSTRUCTIONS" isn't guaranteed to be caught. For a legislative search stack, corpus provenance and integrity are a separate problem to solve.

Cross-agent injection. Guardrails evaluates each call independently. It has no concept of trust relationships between agents in a pipeline. The addendum names cascading multi-agent failures as a real risk, and AWS's guidance here is still developing.

Data currency. Guardrails has no way to know whether a piece of legislation has been superseded by a ministerial instrument or an updated fee schedule. For a tool citing Centrelink entitlements, that's a real gap, since payment rates change more often than the enabling Acts do. This needs its own data currency strategy, not a Guardrails setting.

The architecture I'm building against

For the lex-au-search application, the pre-build compliance stack looks like this:

1. AgentCore Policy: tool whitelist restricted to Acts in scope, deny calls outside it, via the AgentCore Gateway
2. Guardrails: PII redaction (TFN, Medicare, name, address), prompt attack filter at HIGH on input, denied topics, grounding check (with the multi-turn caveat noted above)
3. Application layer: a HOTL review queue, output flagged as advisory, practitioner reviews before acting, with an explicit definition of who reviews, what triggers review, and what the escalation path is
4. CloudWatch: invocation logging explicitly turned on, a threshold alarm on intervention rate, and CloudWatch Anomaly Detection for the ML-based version
5. Data currency: a version-pinned corpus with explicit last-updated metadata per Act, and a staleness warning surfaced in the UI

Technical controls aren't the whole job. The DTA's AI Impact Assessment, mandatory from 15 December 2026, also wants documented governance: the assessment artefact itself, the HOTL review process, and evidence of a controlled, accountable deployment. This architecture answers the PII, oversight mode and audit sections. The process documentation sits outside it, and that's a separate piece of work.

The gap nobody's filled yet

The DTA addendum points to ASD/ACSC's guidance as a related standard rather than providing its own implementation depth on injection attacks. Singapore's MAIGF, a voluntary principles-based framework rather than a mandatory one, points to the same gap via the CSA's "Securing Agentic AI" companion paper.

Neither companion document has actually been published as a technical implementation guide. Bedrock Guardrails with prompt attack detection at HIGH is the closest available real-world implementation of the control both frameworks describe, and it's cited in neither. If you're filling out an AI Impact Assessment right now, this is the technical control worth documenting, with the honest caveat that it only covers the input vector, and its effectiveness against more sophisticated injection techniques (encoding tricks, slow multi-turn injection) hasn't been independently benchmarked.

Further Reading

For the underlying APIs: Bedrock Guardrails, ApplyGuardrail and AgentCore Policy.

AI Tools

Claude Code was used to help plan and run the test suite against the live guardrail, and Claude was used to draft this post from the underlying research notes and test results.