Back to News & Insights
Artificial Intelligence September 29, 2026 · 22 min read

AI Agent Governance on AWS: Block Agents, Prove EU AI Act Compliance

I built a synthetic multi-agent loan crew on Amazon Bedrock and made Traccia hard-block a runaway agent, redact applicant PII across every sub-agent, and export EU AI Act audit evidence. Two of my three governance policies blocked nothing - and not because I misconfigured them. Why is the useful part.

AI Agent Governance on AWS: Block Agents, Prove EU AI Act Compliance

Every fact here is verified against an actual run (Amazon Nova Pro us-east-1 on-demand, Strands Agents, and traccia 0.1.29 $0.0008 per 1K input and $0.0032 per 1K output; EU AI Act Annex III credit-scoring obligations apply 2 December 2027). The demo system is SYNTHETIC throughout.

Observability told me the agent approved a loan it should have declined. It showed me the run that leaked an applicant's email into the logs. Then it did nothing, because watching is the only thing it does.

Part 1 of this series put a real observability layer under a multi-agent AWS crew and caught a run that looked healthy while it silently overspent. This part is about the two things observability cannot do: stop the bad run, and hand a regulator the paperwork afterward. So I built a synthetic multi-agent loan-decision crew on Amazon Bedrock, wired it to Traccia, and made four things happen on real infrastructure: a prompt injection hard-blocked before any model call, applicant PII redacted across every sub-agent's trace, EU AI Act evidence stamped on every span, and the platform itself denying a runaway agent with a real, cited decision.

Then it did not work. Two of the policies I wrote denied nothing, and not because I misconfigured them: two of the three policy types structurally had no signal to match in this crew. Working out why is the most useful part of this article, because it is the part nobody writes down.

How I tested this: the build, the afternoon the platform refused to block, the two real bugs I fixed, and the critique near the end are all mine. Everything on screen is real (real Nova Pro calls, real governance decisions, real exported evidence), the crew is synthetic on purpose, and it produces evidence, not compliance - a distinction that runs through the whole piece. The $0 SDK layer needs no account. After Part 1, the 14-day free trial on the premium platform tier (@govern enforcement and the Governance Hub) is what pushed me to dig in and pull out something meaningful for the community, so everything here is reproducible at no cost.

This is for people already running agents on AWS (Strands, CrewAI, LangGraph, or your own loop on Bedrock) who have heard "EU AI Act" enough times to be nervous, and who want runtime guardrails plus audit evidence without rewriting the app around a compliance framework. Where the governance vocabulary is new, I define it the first time it shows up.

If you have two minutes, skip to the platform payoff, and why it did not work at first. The build-up matters, but that section is the point.

Contents Why agent governance is a different problem The crew, and why it is synthetic Two layers, and only one needs a key Prerequisites The three $0 governance beats The platform payoff, and why it did not work at first The evidence a regulator asks for Real-time enforcement vs scheduled detection The timing that makes this worth doing now An honest take on Traccia governance Honest caveats FAQ

Observability answers "what did the agent do, and what did it cost." Governance answers a harder pair: "can I stop it from doing the wrong thing, and can I prove what happened." Those are not the same layer, and a trace alone gives you only the first.

For a deterministic service, governance is mostly access control and input validation. Both are loud, and both are enforced at the edge before any work starts. An AI agent breaks that. It decides its own control flow, so a block has to interrupt a reasoning loop that is already running. It calls tools in an order you did not hardcode, so a runaway is a genuine failure mode, not a hypothetical.

And when it is a multi-agent crew, the failure surface multiplies three ways. A block has to stop the whole crew, not one sub-agent. Redaction has to cover every span in the tree, not just the entry point. And the agent that actually burns the budget may be three delegations deep from the one you wrapped.

There is regulation attached to this now, not just good practice. The EU AI Act names credit scoring as a high-risk use (Annex III, point 5(b)) and attaches concrete obligations: record-keeping (Article 12), transparency to deployers (Article 13), human oversight (Article 14), post-market incident reporting (Articles 72 and 73), and for some deployers a Fundamental Rights Impact Assessment (Article 27). Article 50 transparency, telling a person they are dealing with AI, is already enforceable. So "governance" here is concrete: a specific list of things a specific regulator will ask you to show.

A quick vocabulary anchor, because the rest leans on it. A guardrail inspects an input, an output, or a tool call and decides whether it is allowed. A policy is a rule the platform enforces at runtime (a spend cap, a tool-call cap, an allowed-model list). Enforcement is what happens when a policy matches: the call is denied. Evidence is the durable record of all of it. The whole article is putting the right guardrails and policies on the right agents, then reading the evidence back.

A supervisor loan officer delegates to three specialists, using the AWS Strands agents-as-tools pattern, each calling Amazon Nova Pro (amazon.nova-pro-v1:0). Intake parses the applicant's free text into an id and a requested amount. PII lands here first, which is why redaction gets tested here (though it covers every span). Credit & Risk (credit-risk) calls a mock creditscore tool and a region-restricted pullbureaureport. This is the agent that makes the tool calls. Remember it, because it is the whole plot of the platform-block section. Policy applies a deterministic, explainable lending rule (income-to-debt and requested-amount-to-income, never a protected attribute) and returns approve, refer, or decline.

Two more guardrails sit at the boundary alongside the injection block: an output-validation check that rejects any recommendation making an absolute approval claim, and a fairness check that rejects a decision if a protected attribute drove the score. Fairness carries real weight here, because it is the whole reason credit scoring is high-risk under the EU AI Act. So the crew asserts on the scoring signals and blocks if a protected attribute ever appears.

Multi-agent earns its place too. It makes governance harder in exactly the ways that matter, and a single-agent demo hides all three problems: the block has to stop the whole crew, the redaction has to span the whole tree, and a crew can genuinely run away, so a loop cap is believable rather than contrived.

Now the honesty that has to be up front: the credit score is a mock. There is no real bureau, no real model decision, no real applicants. The scoring is a deterministic heuristic that uses only legitimate financial signals and, by construction, never touches a protected attribute (there is a unit test that asserts exactly that). A real high-risk credit system needs a legal conformity assessment; this project produces the evidence substrate such a system would generate, not the compliance itself. I label everything "synthetic" on screen for the same reason: a governance demo that pretends to be a real lender is the opposite of trustworthy.

Traccia's governance splits into two layers, and getting the split right is most of this article.

Want to discuss this further?

Book a free strategy call with our team to see how these insights apply to your specific business goals.

Book a consultation