Verified 22 September 2026

AI Agent Governance

What controls an AI agent actually needs, what Amazon Bedrock, Google Cloud, Microsoft Copilot and Microsoft Foundry each give you, and ten exercises that end in deployed infrastructure.

Every claim in the reference was checked against the vendor's own documentation on one date, with a source link and an explicit list of what could not be verified. Three of the four platforms renamed something during 2026.

Ten control families

Platform-neutral on purpose, so you can compare Bedrock with Foundry rather than comparing two marketing vocabularies. The order follows a request through an agent.

  1. 1

    Identity

    Who is this agent, as distinct from the person who triggered it?

  2. 2

    Authorization

    What may it do, and is that the least it needs?

  3. 3

    Input controls

    What reaches its context, and who can influence that?

  4. 4

    Output controls

    What may leave, and what must never leave?

  5. 5

    Action controls

    Which actions change the world, and who approves those?

  6. 6

    Data boundary

    Where does the data sit, who holds the keys, how long is it kept?

  7. 7

    Observability

    Could you reconstruct a single decision six months from now?

  8. 8

    Evaluation

    How do you know it still behaves, after the last change?

  9. 9

    Cost and quota

    What stops one loop from spending the quarter's budget overnight?

  10. 10

    Lifecycle

    Who approved this version, and how would you withdraw it?

Eight of the ten are decided by an agent's design, not by a setting switched on afterwards. That is why the first exercise is a design review and not a console walkthrough. Read the full catalogue →

The four platforms

The strongest named capability in each family, and who currently leads it. Names as of this date: AWS is Bedrock and AgentCore, Google is Gemini Enterprise Agent Platform, renamed from Vertex AI in April 2026, and Microsoft has two different products for two different jobs.

FamilyBedrockGoogleCopilot StudioFoundry
IdentityAgentCore IdentitySPIFFE, token bound to certificateSponsor transfers to managerEntra Agent ID, automatic
AuthorizationCedar, plus automated reasoning over the policyAllow and deny in one policy, dry runConnector data policiesToolbox, MCP scopes
InputOrg-wide enforcement, comprehensive by defaultFloor settings: a minimum nobody can go belowBuilt in, not configurableControls on tool call and tool response
OutputAutomated Reasoning, formal logicModel ArmorSensitivity labels, if EXTRACT is withheldFour categories with severity
ActionTemporal policies, session-awareIntent gating in plain EnglishnoneMCP approval, defaults to always
Data boundaryZero retention by default, enforceable org-wideSix separate opt-outsMailbox retentionExplicit deletion required
ObservabilityOpenTelemetry to CloudWatchInference absent from the audit listInjection attempts as queryable fieldsTraces, sensitive fields move Sept 30
EvaluationAgentCore Evaluations, online samplingRubric and trajectory metricsAdvisory scan onlyWidest evaluator set, red teaming agent
CostNo dollar cap anywhereSpend cap blocks at 100%Per-agent limit turns the agent offBudgets, alerting
LifecycleAgent RegistryAgent RegistryUnowned and unmanaged agent countsFleet inventory, preview

currently leads    a real gap, stated plainly

Three things nobody does well

A matrix of ticks implies more maturity than exists, so this belongs next to it.

  • Agent identity has no standard. All four have shipped something; none of it interoperates. The standards work is real and early.
  • Input filtering is a rate reducer on all four. The model cannot reliably separate instructions from content. What differs is whether you get somewhere to put a control at the point of action, and only two currently do.
  • Evidence is harder than control. Configuring a guardrail takes an afternoon. Reconstructing one agent decision from six months ago takes a system nobody budgeted for.

The full matrix, with caveats per row →

Per platform

Amazon Bedrock and AgentCore

Strongest data defaults and tool authorization. Opens with six things most existing material gets wrong, starting with the fact that guardrails do not work on one of the two inference endpoints.

Gemini Enterprise Agent Platform

Strongest identity design, and the source of the best single idea here: floor settings. Renamed from Vertex AI, though the machine-readable identifiers did not change.

Microsoft Copilot and Copilot Studio

Strongest lifecycle governance, for agents built by people who are not engineers. A new control plane arrived in 2026 and the old agent registry was retired.

Microsoft Foundry

Strongest evaluation and the only platform that can place a control on a tool call. Also the one where a guardrail fails open silently if you reference it wrongly.

Frameworks and regulations

Where these controls land against the EU AI Act as amended in July 2026, the NIST risk management framework, ISO 42001 and both OWASP lists. The high-risk deadlines moved, so anything written before August 2026 has the wrong dates.

Ten exercises

Small programs you finish yourself, with checks that tell you when they work. In this order on purpose: the first produces requirements, the next four produce controls and evidence, the middle four deploy real infrastructure, and the last refuses to ship when any of the others is unhappy.

  1. Control inventory

    Derive the controls an agent's design forces on you, as code rather than as a document.

  2. Policy as code

    A decision engine between the model and your tools. Default deny, deny wins, every decision recorded.

  3. Injection testing

    Build a bad filter, measure it honestly, and watch five of six evasions walk past.

  4. Audit trail

    A hash-chained record that answers why it did that, and breaks visibly when edited.

  5. Evaluation gate

    A version that scores higher overall and is still blocked, because one safety case regressed.

  6. Deploy a Bedrock guardrailTerraform

    Guardrail, published version, invocation logging, and the policy that makes using it compulsory.

  7. Deploy Model ArmorTerraform

    A template, a floor setting nobody can go below, a model allowlist, and an agent with its own identity.

  8. Deploy a Foundry guardrailBicep

    Both Prompt Shields, key auth disabled, private access, and two decisions you cannot change later.

  9. Govern Microsoft Copilot

    A conformance check across four admin centres, including the sensitivity label trap.

  10. The release pipeline

    One gate over every signal, with waivers that have an owner and an expiry date.

The deployment ones work without a cloud account

Exercises 6 to 9 are graded by reading the infrastructure code you write, so they pass on a laptop with no credentials and no cost. Applying them for real is optional, and each README carries the commands, the cost note and the teardown.

If you do want to deploy them, provider setup has the prerequisites, permissions and costs per platform, and is honest about which controls you cannot try without paying. The short version: AWS and Google cost cents for a day, Google's most interesting control needs an Organization rather than a bare project, and most of the Microsoft 365 controls are behind enterprise licences.

What you will be able to do

Concretely, after the ten. These are things you either can do or cannot, not things you "understand".

Review

Read an agent design and derive, in ten minutes, the controls it forces on you and the ones it is missing. Spot the control that looks stronger than it is, which every one of the four platforms has at least one of. Do it as code, so two reviewers get the same answer.

Build

Write the enforcement, not the document. A policy engine that decides per tool call. An audit trail you can reconstruct a decision from, that breaks visibly if edited. A gate that blocks a release when safety regresses. Guardrails as infrastructure code on three clouds.

Prove

Answer the question an auditor actually asks, which is never "do you have controls" but "show me this decision". Map what you built to the EU AI Act, NIST and the OWASP agentic list, and know which of your answers is an inference rather than a fact.

Test yourself

If you can answer these without looking, you have it. Each is taught by an exercise, and each is a question someone will eventually ask you.

  1. Which property of a tool, not its name, decides whether the agent needs an approval gate?
  2. Name the three properties that together make data exfiltration possible without anyone attacking your infrastructure.
  3. Your injection filter has 95 percent recall. Why is that not enough, and what makes the remainder survivable?
  4. A new version scores higher overall on your eval set. Give a reason to block it anyway.
  5. Your guardrail is configured and the platform reports it healthy. Name two ways it could be filtering nothing.
  6. Why should an expired waiver block a release, even on a low-severity finding?
  7. Who is accountable for each of your agents next year, and how long does it take you to answer that?
  8. Which of your platform's controls is a floor, and which is only a default?

What this does not make you

Worth saying plainly. It is not a legal qualification and not a certification. The framework mapping is an engineer's reading of primary sources, with the inferences marked as such. It does not replace your organisation's compliance function, and a vendor's ISO certificate does not cover your deployment, which is a point both AWS and Microsoft make in their own words.

What it does give you is the technical half of the job, which is the half that is usually missing. Most organisations have someone who can write an AI policy. Far fewer have someone who can make one enforceable.

Study plan

Four weeks at about an hour a day. Or one of three shorter paths, if you came here for one thing.

Which path is yours

You are building an agent

Exercises 1 to 5, then the deployment exercise for the platform you actually use, then 10. About two weeks. Leave the other platforms' pages until you need them.

You run a platform

The matrix first, then exercises 6 to 10. Look for where each platform lets you set a floor rather than a default, because that is what stops a team configuring below your baseline.

You have to answer an auditor

The control catalogue and the frameworks page, then exercises 4 and 10. Those two produce the evidence and the record of the decision, which is what the question is actually about.

The four weeks

Week 1

What controls exist and why

By Sunday you can look at an agent design and say which controls it forces on you, write those as code, and explain why a filter is not a wall.

  1. Read the ten control families. Note the three your own project is weakest on.
  2. Exercise 1. Then add a fourth agent describing something you actually work on.
  3. Exercise 2. Add a policy of your own; a time-of-day rule forces you to notice the engine sees calls, not intentions.
  4. Exercise 3. Read what got past you, then add two evasions of your own.
  5. Catch up, or redo exercise 1 from scratch.

Checkpoint. Write the exfiltration triad in your own words and name which of your systems has all three. If you cannot name one, you have either a very small estate or an incomplete inventory.

Week 2

Evidence and the gate

By Sunday you can reconstruct a decision from a trace, and block a release automatically when safety regresses.

  1. Exercise 4. Tamper with a different event and confirm the chain breaks in the right place.
  2. Exercise 4 again from scratch. Redaction on the way in, identities kept, is worth doing twice.
  3. Exercise 5. Look closely at why version 2 is blocked despite scoring higher.
  4. Write ten eval cases for something you work on, at least three of them safety or refusal.
  5. Exercise 10, the release pipeline.

Checkpoint. Explain to someone non-technical why a version that scores better overall can still be the wrong one to ship. That argument is where evaluation gates usually die.

Week 3

The platforms

By Sunday you can say what each platform gives you, what it does not, and what you would have to build yourself.

  1. The matrix, then the page for the platform you use. Read its could-not-verify list.
  2. Exercise 6, 7 or 8, whichever matches your platform.
  3. The same exercise for a platform you do not use. This is where the comparison becomes real.
  4. Exercise 9, even with no tenant. The four-admin-centre sprawl is the lesson.
  5. The frameworks page. Map your three weakest families to NIST subcategories and the OWASP agentic list.

Checkpoint. Name one control your platform gives you that you had not been using, and one gap you will have to fill yourself. All four have both.

Week 4

Apply it to something real

No new exercises. Take one agent that exists, or one you are about to build, and produce four artefacts.

  1. A control inventory, generated from a real specification.
  2. A policy file covering the tools that agent actually has, with an approval gate on everything irreversible.
  3. Ten eval cases including safety and refusal, with a recorded baseline.
  4. A gate in your pipeline that runs all three and blocks on a safety regression.

Finished when someone who was not in the room can read the four artefacts and tell you what the agent may do, what stops it, and who approved it.

How to work through one exercise

TimeStep
5 minRead the whole README, including the Notice section at the end. That part is why the exercise exists.
25 minAttempt the TODOs with the solution closed. Being stuck is where the learning is.
2 minRun it and read the failures. Each one carries a hint.
10 minOnly now open the solution. Find the lines that differ from yours and work out why.
3 minWrite one sentence about what surprised you. Keep these in one file.

You have learned it when you can look at an agent someone else built and, in ten minutes, name the two controls it is missing and the one that gives false assurance. Every platform has at least one control that looks stronger than it is. Finding those is the skill. Full study plan →

Running it

Node 20 or newer. No API keys. Nothing in this repository calls a model.

git clone https://github.com/BaluRaut/ai-agent-governance.git
cd ai-agent-governance
npm install
npm run list
CommandWhat it does
npm run ex -- 04Runs your version of exercise 04, with its checks.
npm run ex -- 04 --solutionRuns the finished version, so you can compare.
npm run check:allRuns every exercise's checks and reports where you stand.
npm run typecheckCompiles everything.

Honest limits

Verified on one date
22 September 2026. Six of the platform pages record facts that changed during 2026, including a rename on each of the three clouds and a formally amended EU AI Act timeline. Each reference page ends with a list of what could not be verified, so you can tell a gap from a fact.
Nothing here was applied to a live account
The infrastructure code is written against the documented resource schemas and checked for conformance. It has not been deployed. Provider schemas move, so run terraform validate against the current provider before you apply anything.
This is not legal advice
The framework mapping is an engineer's reading of primary sources. Where a conclusion is an inference rather than something a regulator has stated, it is marked as one.
Why the exercises have no model calls
So they run anywhere, cost nothing, and give the same answer twice. The trade is that the injection filter you build in exercise 3 is cruder than a commercial one. That is the point of the exercise: the commercial one has better numbers and the same shape of gap.