Agent Governance, Part 2: Building the Charter That Makes It Real
Part 1 of the Agent Governance series established that traditional governance does not meet the requirements of AI Agents and introduced the three-tier decision-rights structure. If you have not read Part 1, do so first.
Defining the three tiers of approval with what they can approve is the start. How you protect that boundary as the agent runs, how you distinguish a routine change from a governance event, or how you keep governance current when the world changes around it. That is what this article covers.
Where do you record your governance?
Currently, there is little to no standard tooling for capturing decision rights or Agent Boundaries. Start with documentation; eventually, you will need a graph database (my recommendation) to map all processes, data, and agent relationships.
Boundary Management: What the Agent Is Allowed to Do
The agent’s boundaries are the most important thing governance protects. They define the blast radius of a wrong decision. (If you ask what a blast radius of an agent is and get blank stares, I would be worried.) They define what the security controls are meant to contain. They define what a human reviewer is actually reviewing when they approve an action.
Boundaries degrade in two ways. The first is explicit expansion, where someone decides the agent should do something new and makes the change without going through the governance tier that the change requires. The second is implicit drift: the agent starts handling cases that were never explicitly authorized because no one noticed it had begun.
Most governance frameworks stop at listing what the agent can do. I recommend that you go further and cover the implications of an agent failing, the blast radius, and the consequences of failure.
Defining the Agent Boundary
The boundary definition maps the agent’s authorized scope, data flows, tool access, and process design before deployment. Governance owns the process by which that boundary is set and changed.
Different agents have different blast radii. An agent that writes to a CRM and triggers an outbound email sequence has a very different blast radius than one that summarizes documents. The governance framework must reflect this difference.
The more systems depend on an agent, the larger the blast radius. Changes to its scope, data access, or behaviour have consequences downstream. If you cannot draw that map before you define the boundary, everything that follows is governance theatre. The following six items must be captured during boundary definition.
Downstream impact:
- What are the downstream systems, processes and people that the agent impacts?
Downstream Data:
- What data does the agent write, and where does it go? Every system that reads the agent’s output inherits any errors it makes.
Tool access:
- Outbound tool access, which tools the agent can call, the specific APIs and permissions for each, and whether access is read-only or read-write.
- Inbound tool access to the agent, which systems, agents, or users are authorized to call this agent via API, under what authentication, and with what scope of instruction?
- Reviewing tool access, inbound and outbound access must be reviewed at the same frequency.
Data access:
- Which data sources does the agent have read/write access to?
- Does the agent have destructive data access, such as delete or change?
- Have you identified the trust tiers for each source as we discussed previously?
- For each source, document who owns it, how frequently it is validated, and which upstream systems feed it. Even with proper data management, this needs to happen.
Action scope:
- The actions the agent is authorized to take autonomously, the actions that require HITL (Human In The Loop) approval, and the actions that are explicitly prohibited, regardless of what the agent is instructed to do.
Workflow scope:
- The specific workflows the agent is authorized to participate in. If a workflow is not listed, the agent is not authorized to run it. What is the fallback if an agent fails continuously?
Remember that running in parallel before launch verifies that the work done during boundary definition is correct.
Agent Playbook
The Agent Playbook captures everything the agent needs to know and everything the organization needs to have decided before a workflow step runs. Every subsequent article in this series adds a layer to it.
The six items above define the boundary. The Playbook maps each authorized workflow step against its data requirements, HITL mode, and blast radius. The boundary tells the agent what it is allowed to do. The Playbook tells it what it needs to know to do it. Both are required before going live.
An example implementation is shown below; adjust to your specific needs.
Protecting the Boundary
Think of your boundary as the “thermal exhaust port” of your entire governance strategy. If you don’t shield it, one small, unvetted change can blow up the whole station. To keep your deployment from drifting into chaos, you need three specific high-alert controls.
Boundary Controls
- Upstream Changes: Quarterly, the Technical Owner needs to determine if any source for the agent has changed. This means checking data ownership, API schemas, or third-party connector behaviour. A boundary that worked perfectly in January can be broken by March, even if you haven’t touched the agent itself.
- The CAB Checkpoint: Change Advisory Board (CAB) review before a single line of code moves. The Technical Owner raises the ticket, while the Business Owner confirms the “blast radius” has been fully mapped. If your organization doesn’t have a CAB, then a direct notification to downstream owners is the absolute minimum requirement to keep the lights on.
- The Tier Two Sign-off: Modifying tool access, data permissions, or the scope of a workflow isn’t a “quick fix” or an operational tweak. It is a governance decision. These changes stay on ice until the Business Owner signs off and the decision is officially recorded.
Validation Mechanisms
- Quarterly Boundary Audit: The Technical Owner creates a report that compares how the agent actually behaved against its authorized boundary. If the agent called a tool or touched data it wasn’t supposed to, that is a finding and needs to be reported.
- Incident Review Triggers: Every incident report must ask: “Was the agent operating within its authorized scope?” If it were, the boundary might need to be tightened. If it wasn’t, you have a governance failure that needs to be named and addressed.
As Christof said in The Truman Show: “We accept the reality of the world with which we’re presented.” In agent governance, you shouldn’t just accept how the agent is behaving; you audit it to measure that reality matches what you authorized.
Review Triggers: Formal vs Operational
Not every change to the agent’s environment requires a formal governance review. The distinction is simple. An operational change is one that keeps the agent functioning within its existing authorized boundaries. A governance event is one that changes something material about what the agent is, what it can do, or who is accountable for it.
Pay careful attention to the model provider update row. When your model provider pushes you to a new version, it is a net new model, and your agent’s behaviour may change in ways your last regression suite did not anticipate. The Technical Owner triggers the regression testing with downstream systems and users. The Business Owner approves re-entry to full production traffic. Neither of those steps should be skipped, even though the change was external.
The Governance Charter
The Governance Charter is the document that operationalizes governance. It is a record of the names, boundaries, decisions, and dates. When an incident occurs, when a regulator asks, when a staff member leaves, and their replacement needs to understand what they own, the Charter is the answer.
Get Gordon Deudney’s stories in your inbox
Join Medium for free to get updates from this writer.
The Charter has six components. All six are required. A Charter missing any of them is not a Charter. It is a starting point.
Component One: Named Roles
The three names every agent deployment must have on paper before a single line of code is written.
If the same name appears in Technical Owner and Business Owner, that is not a filled Charter. That is an ownership vacuum with a name.
Component Two: Authorized Boundary
The specific tools, data sources, action scope, and workflow scope the agent is authorized to operate within. This is the output from defining the boundary. Any change to this section requires at least Tier Two approval. What is the blast radius if things fail?
Component Three: Decision Rights Log
A running record of every Tier Two and Tier Three decision made about this agent. Each entry includes the date, the decision, the rationale, and the names of the people who approved it. Operational decisions are logged in the changelog, not here.
Component Four: Review Trigger Log
A record of every governance event that has occurred and how it was handled. Model updates, scope changes, and incident reviews that triggered a boundary check. The Business Owner reviews the log quarterly.
Component Five: Escalation Path
The specific path for decisions that exceed the Technical Owner’s authority. Named individuals, not titles. Response SLAs for governance decisions. What if the Business Owner is not available?
Component Six: Charter Review Date
The Charter is reviewed quarterly. The review date is set to the previous review date. Missing a review date is a governance finding.
The Charter is a living document (not in the sentient sense, but in the “you must keep updating it” sense). The version from the day the agent went live is a historical record. The current version reflects the agent as it actually operates today, the boundary as it currently stands, the roles as they are currently filled, and the decisions as they have been made. If those two versions look different, the difference is your governance history.
Spreading the Word
If you build a governance framework and tell no one, you haven’t created “governance”; you’ve created a very well-documented secret. Unlike Fight Club, “The first rule of Agent Governance is, you talk about Agent Governance.”
(Road show time.) You must explain to the various teams why governance exists and educate them about the risks associated with agents.
Guidance on Communication
- Own the disclosure. Don’t hide the “Agent-assisted output” label; ensure it is clear and easy to spot. If that agent makes a call that hits someone’s rights or status, they shouldn’t be trapped in a loop with a bot. Give them a path to a real human being. Period. As they say in every legal department ever: “If it is not documented, it did not happen.”
- No surprise updates. If you are flipping the switch on a model update or shifting the boundaries, tell your team before it goes live. When staff see an agent acting weird and haven’t been warned, they either stay silent,t masking a real problem, or they just stop using it.
- Have a defined feedback loop. Have a dedicated feedback loop for your agent. You need a named owner and a clear response timeline. This is how you catch the stuff a dashboard misses, like a manager noticing that the math hasn’t made sense since last Tuesday. This is the “canary in the coal mine,” except this canary has a Slack handle and a direct line to the boss.
- Stay ahead of the drift. As they said in Jurassic Park: “Life finds a way.” In this case, your agent’s behaviour will drift. If you aren’t talking to the people it affects, you won’t know it’s happening until you’re staring at a compliance finding.
Keeping the Charter Alive
Governance documents age, models update, regulations shift, and people change roles. An outdated Charter describes an agent that no longer exists.
The Maintenance Schedule
- Mandatory Quarterly Reviews: You must confirm that roles are accurate, boundaries are correct, and all governance events were logged. If you can’t answer these, you’re not done.
- Upstream Change Triggers: When a provider updates a model, it’s a governance event, even if you didn’t request it. As Dr. Ian Malcolm might say: “Your model provider was so preoccupied with whether they could update the model, they didn’t stop to think if they should wreck your regression suite”.
- Annual Framework Audit: Once a year, step back and ask if the three-tier structure still fits the risk profile.
The IMDA’s Model AI Governance Framework for Agentic AI notes that governance frameworks need to be continuously updated regarding new developments. That is not a caveat. It is a requirement. An agent governance framework that was well-designed at launch and never updated describes an agent that no longer exists.
Before You Build: Your Monday Morning Checklist
Conclusion
Nobody has figured out agent governance completely(trust me, I have looked). The tooling is immature, the regulatory landscape is still forming, and most organizations are doing the best they can. The Governance Charter does not solve all of that. The Governance Charter addresses the fact that no one wrote anything down, no one owns the decision, and no one can explain what the agent was authorized to do.
The Charter exists so that the call has an answer before it arrives. (To borrow from Apollo 13: the time to figure out the solution is before Houston has a problem.)
The ones that skip it are the ones building the Charter retroactively, in the middle of an incident, while the agent keeps running.
What’s Next: B3 Data Readiness as a Product.
