What is AI agent governance?
AI agent governance is the set of controls that decide what an AI agent is allowed to do, prove what it actually did, and keep a named human accountable for both.
The short answer
An AI agent is not a feature, it is an actor. It holds credentials, calls APIs, changes systems and spends money. Once you accept that framing, the governance questions stop being novel and start being familiar: what access does it have, who gave it, who approved this particular action, and what is the record afterwards.
The thing that makes agents specifically hard is that they are self-reporting and persuasive. A traditional automated job either exits zero or does not. An agent produces a paragraph explaining that everything went well, which is the most likely continuation of the conversation whether or not it is true. Governance is what replaces that paragraph with evidence.
What are the parts of agent governance?
Six controls. They compose: each one is weakened by the absence of any other.
Identity and authority
The agent acts as ITSELF, not as the human who started it. Every action traces to a role with an identity, and an action outside that role's authority is refused rather than borrowed from the operator.
Least privilege
Access is granted per role, per service, explicitly and revocably. No agent may widen its own permissions, and no fallback path may quietly widen them either.
Approval and separation of duties
Sensitive actions become requests routed to whoever is accountable. The producer of a change is never its approver, and the approval record names the decider.
Verification evidence
Progress gates on results the agent did not generate: a command exit code from the project's own checks, run independently. A summary of a test run is not a test run.
Credential handling
Secrets live in a keychain or secret store, are injected at execution, and are redacted from logs and from the model. An agent uses a credential without ever being able to repeat it.
Audit trail
An append-only record of every elevated action and the authority it ran under. Tamper-evident, so the record is worth something in the situation where it matters most.
What does a governed action look like?
One change, from instruction to delivery. Each step says who decides it, and the blue ones are decided by rules rather than by anybody’s judgement.
- InstructionYou
- Routed to a roleDeterministic gate
- Work in isolationAgent
- Verified on exit codeDeterministic gate
- Reviewed by a different agentAgent
- Approval for deliveryYou
- Draft pull requestDeterministic gate
Nothing in that sequence depends on the agent being honest, capable or well-prompted. An agent that lies about its test run does not get past step four, because step four is not asking it. An agent that writes a plausible but wrong change does not get past step five, because step five is a different agent that did not write it. An agent that decides on its own to deploy does not get past step six, because that authority was never granted to the role it is acting as.
That is the whole idea: governance is what makes the system's correctness independent of the agent's self-assessment.
Questions worth asking of any agent platform
- Whose identity does the agent act under, and what happens when it lacks access: is the action refused, or does it fall back to the operator?
- Can an agent grant itself a permission, directly or by installing something that has one?
- What evidence is required before work is considered done, and could the agent have produced that evidence itself?
- Can the agent that made a change approve it?
- Where do secrets live, and can the model read them back?
- Is the audit record append-only, and would you notice if it had been edited?
- Which actions require a named human, and is that list configuration or convention?
- When something goes wrong, what exactly can you reconstruct?
How Orgabot implements this
Orgabot puts governance in the org chart rather than in a policy document. A mission is owned by a role, the role holds capability packs and connector grants, and those grants are what bound every action the mission can take. Where a role has a configured connector for a service and that connector is unavailable, the mission HOLDS and surfaces the block rather than reaching for your personal credentials, because falling back would silently re-attribute the action to you and usually widen its authority. That is the boundary worth checking in any tool: not whether it can act, but what it does when it cannot.
Being precise about it, because this is exactly the question the checklist above asks: that hold applies where a role HAS a configured connector. On a fresh install, before you have configured one, a mission reaches GitHub through your own credentials, the same way any local tool on your machine does. Configuring a connector is what moves an action from your identity to the role's.
Verification is an exit code from your own test command, run by Orgabot rather than by the worker. Review is an agent that did not write the change. Sensitive actions become approval requests routed to the inbox of the role accountable for them. Credentials live in the OS keychain, are injected at execution and are redacted from logs and from the model. Every elevated action, and the authority it ran under, lands in a hash-chained, tamper-evident ledger.
Common questions
- How is agent governance different from AI governance?
- AI governance is mostly about the model: which model you use, what it was trained on, what it may be used for, how bias and safety are assessed. Agent governance is about the actions. An agent holds credentials, calls APIs, writes to repositories and spends money, so the questions are the ones you would ask about a contractor: what access does it have, who granted it, who approved this specific action, and what is the record. A perfectly governed model with an ungoverned agent around it is an unbounded actor with good intentions.
- What does least privilege mean for an AI agent?
- That the agent holds only the access its current job requires, granted explicitly, scoped narrowly, and revocable without touching anything else. In practice the failure is almost never a malicious agent; it is an agent that inherited a developer’s personal credentials because that was the easiest way to make the demo work, and now has whatever that human has. Least privilege means an agent that cannot reach a service is BLOCKED, not silently upgraded to the operator’s identity.
- Why can an agent not approve its own work?
- For the same reason a developer does not merge their own pull request, and for a sharper reason on top of it: the agent that produced a change is conditioned on the reasoning that produced it, so it is the single worst-placed evaluator of whether that reasoning was wrong. Separation of duties is not bureaucracy here, it is the only structural defence against a confident mistake. The reviewer must be a different agent or a human.
- What belongs in an agent audit trail?
- Every elevated action, the authority it ran under, the identity that granted that authority, and the evidence the action was based on, in order, append-only. "The AI opened a pull request" is not an audit record. "Role X, holding grant Y approved by human Z on date D, opened pull request N after test command C exited 0" is. The distinction matters the first time something goes wrong and someone has to reconstruct what happened.
- Does governance mean a human approves everything?
- No, and a system that requires it will be switched off within a week. Governance means the boundary is decided in advance and enforced in code rather than negotiated per task. Low-risk actions run unattended, sensitive ones become an approval request routed to whoever is accountable for that domain, and the boundary itself is configuration under version control rather than a habit.
- How do you keep credentials out of the model?
- By never putting them there. Secrets live in the OS keychain or a real secret store and are injected at execution time into the process that needs them, never into a prompt, and are redacted from logs and from anything the model can read back. An agent should be able to USE a credential without being able to REPEAT it, because everything a model can read is something it can be talked into emitting.
Governance you can point at, not a policy you hope people follow.
Scoped grants, routed approvals, independent verification, and a tamper-evident ledger, on your own machine.