How identity, policy, configuration and infrastructurecome together in one pipeline, so every agent is governed by design, not by memory.
Over the last four articles, we turned four questions about AI agents into code:
Who is the agent?
What may it do?
How does it behave?
Where does it run, and how do we stop it?
Each layer is valuable on its own. But real failures rarely stay inside one layer, and real governance cannot either. This final article puts the pieces together.
In this article, you will learn:
The big picture: how the four layers answer four different questions
The package: how one agent's governance fits in one repository
The pipeline: eight steps from a pull request to a governed agent in production
The evidence: how the pipeline answers auditors and regulators by design
The operating model: who owns what, and how to start
1. Four Questions, Four Layers
No single control can govern an agent. Four layers working together can.
Identity as Code: who the agent is, who owns it, what it may ever touch and when its access expires.
Policy as Code: whether a specific action should happen right now, decided outside the model before every tool call.
Configuration as Code: how the agent behaves, through its pinned model, prompt and settings.
Infrastructure as Code: where the agent runs, what it can physically reach and how to stop it.
Why one layer is never enough
Look again at the April 2026 PocketOS incident, where a coding agent deleted a production database and its backups in nine seconds.
It was not one failure. It was three:
An identity gap: the agent held a token with far more power than its task needed.
A policy gap: a destructive action ran without any check or human approval.
An infrastructure gap: the backups sat inside the same blast radius as the data they protected.
Closing any one of these gaps would likely have reduced the damage. Closing all three would likely have prevented the incident.
Incidents cross layers, so governance has to cross them too.
2. One Agent, One Package
When everything about an agent lives in one place, everything about it can be reviewed in one place.
The simplest way to connect the layers is to keep each agent's governance together in one repository folder, its agent package:
Identity file: owner, backup owner, purpose, risk tier, tools, data and expiry date.
Policy set: the access, limit, escalation and sequence rules that apply to this agent.
Configuration file: pinned model, prompts, settings and evaluation gates.
Infrastructure definition: sandbox, network allow list, storage and kill switch levels.
Tests: policy tests, behavior evaluations and infrastructure checks.
Evidence: approvals, test results and release history, produced automatically.
Templates make this scale. A new agent of a known type, such as a research assistant or a reconciliation agent, starts from an approved package and only the differences need a full review.
A complete agent package turns a scattered set of approvals into one story anyone can follow.
3. The Pipeline, Step by Step
The pipeline is where good intentions become enforced habits.
Propose: every new agent and every change starts as a pull request against its package.
Check automatically: policy checks reject unsafe changes before a human looks, such as write access without a risk tier, a floating model alias or unrestricted outbound network access.
Test: run the policy tests, the behavior evaluations against the golden dataset and the infrastructure scans.
Review by materiality: cosmetic changes need the owner, behavioral changes add a second reviewer, and material changes add risk sign-off.
Release gradually: shadow mode first, then a small share of traffic, with automatic rollback triggers.
Run under enforcement: credentials issued at runtime, every tool call checked at the gateway and every session inside its sandbox.
Monitor and detect drift: compare what is running with what is declared, and watch behavior for changes nobody approved.
Renew or retire: when the expiry date arrives, the owner renews with a reason or the pipeline suspends the agent and retires its access.
The rule that holds it together: nothing reaches production except through this pipeline. Remove manual console rights once the path works, or the pipeline becomes optional.
If there is a side door into production, the pipeline is a suggestion. Close the door, and it becomes the control.
4. Evidence by Design
The best audit evidence is the kind nobody had to prepare.
When the layers share one pipeline, every action an agent takes can carry four version numbers:
The identity version
The policy version
The configuration version
The infrastructure version.
That single link answers the questions every reviewer asks:
Who acted: which agent, on whose behalf and with whose approval.
Under which rules: the exact policy in force at that moment.
With which setup: the model, prompt and settings behind the decision.
From where: the environment, its network limits and its isolation.
Who approved the change: the pull request, the reviewers and the test results.
Where expectations are heading
Identity and accountability: the NIST NCCoE concept paper on software agents, released in February 2026, focuses on identification, authorization, auditing and non-repudiation.
Record-keeping: Article 12 of the EU AI Act requires high-risk AI systems to automatically record events over their lifetime.
Banking: SR 26-2 keeps generative and agentic AI outside its formal scope, but banks are still expected to govern them through their broader risk management.
A pipeline that records every decision turns an audit from an investigation into a lookup.
5. The Operating Model: Who Owns What
Code makes governance repeatable. People make it accountable.
Business owner: accountable for the agent's purpose, renewals and retirement.
Platform engineering: owns the pipeline, templates, gateway and sandboxes.
Security: owns identity standards, network rules and the kill switch.
Risk and compliance: translates obligations into policy intent and signs off material changes.
Internal audit: tests whether the pipeline itself works, rather than reviewing each agent by hand.
A practical 90-day start
Days 1 to 30: inventory every agent, pick the highest-risk one and build its agent package.
Days 31 to 60: run that agent through the full pipeline, with policies in shadow mode and the first two kill switch levels drilled.
Days 61 to 90: switch policies to enforcement, remove console access and turn the package into a reusable template.
This works the same whether the agents serve a bank, a hospital, a manufacturer or a retailer.
Start with one agent through one pipeline, and you have built the operating model for every agent that follows.
Key Takeaways
Govern agents the way you govern software, and they become something you can scale with confidence.
Four layers, one goal: identity, policy, configuration and infrastructure together answer every question about an agent.
One package per agent: keep all four layers, the tests and the evidence in one place.
One pipeline, no side doors: eight steps from pull request to renewal or retirement.
Evidence by design: every action carries the four versions that explain it.
Clear ownership: code makes governance repeatable, and named owners make it accountable.
The organizations that win with AI agents will not be the ones with the most agents. They will be the ones that can explain every one of them.
Which step of this pipeline would be hardest to put in place in your organization, and why? Share your thoughts in the comments.
This is fifth and last article of the five-part series Governing AI Agents as Code.
Thank you for following the series.
Explore more: Start Here · Topics · Archive · About