🚧 Roadmap — The capability described here is on the roadmap. The concepts and design are settled; interfaces and steps are subject to the final release.
Governing an enterprise agent fleet
Zhou Yan is the CISO of a 3,000-person company. At last quarter's security review she asked every department to report which AI agents they were using. The list came back one page long. Then she had her team sweep egress traffic, third-party authorization records, and the service account inventory — the real number was several times the list. Marketing had wired in a content agent. Someone in engineering had hung a review agent off the code repository. That reconciliation script finance had been running for two years had quietly been "upgraded" last quarter into an agent that makes its own decisions. Nobody was hiding anything on purpose. It is just that nobody had ever written down the rule: when you stand up an agent, who do you tell.
This is shadow agent sprawl. Every shadow agent holds some credential — an employee's grant, an all-powerful service account, an API key that never expires — and the security team neither knows they exist nor can answer audit's four questions: how many agents does the company have, and who is accountable for each? Right now, in whose identity and on whose authorization are they acting? What can they access? When something goes wrong, how do we pull permissions back and trace accountability to a person? (For why these four are no longer avoidable, see the incidents and data in Why Agent Identity.) Counting by hand leads nowhere: the list is already out of date the moment you finish it.
The flow
Governance is not a campaign, it's a loop: discover → register → approve → review → kill switch, with each stage answering one governance question.
| Stage | Question it answers | What it produces |
|---|---|---|
| Discover | Where are the shadows? | An inventory built from traffic, third-party authorization records, and the service account list, to surface existing agents and bring them under management one by one |
| Register | Whose agent is this? | One agent, one file: purpose, permission request, Owner, Sponsor — no accountable person, no record |
| Approve | What entitles it to these permissions? | Organization-level consent draws the permission boundary; what an agent actually holds is always the intersection of the approved boundary and its runtime grant |
| Review | Is the ledger still alive? | Who hasn't run in three months, whose permissions have never been used (narrow them), whose behavior has drifted from its registered purpose, whose accountable person has left (ownership transfers automatically) |
| Kill switch | What do we do when something goes wrong? | Disable a single agent in one action, or freeze a whole class if needed — and the act of pulling permissions back enters the audit chain too |
On the full sequence diagram, the governance loop owns the first and last steps: ① puts the agent into the ledger, and ⑦ makes every action queryable and recallable. The ②–⑥ in between are the runtime steps — every delegation, issuance, and access leaves a trail on the audit chain (full sequence in End-to-end business sequence):
In a governance scenario the User lane carries two identities: an employee can withdraw their own grant at any time, and the security team or an administrator can hit the kill switch on the whole agent. Both paths lead to the same place to pull permissions back.
Three moments that matter
- Consent — the organization-level approval moment: what the approver sees is not a pile of scope strings but an application they can actually rule on: what this agent does, who owns it technically, whose business it counts against, which permissions it wants, and why. Approval is the boundary — from then on every action this agent takes is framed inside the approved boundary, and runtime grants (an employee's delegation, a customer's consent) can only narrow it further, never break through it.
- Audit record: every delegation, every token issuance, every resource access carries an
audit_idthat strings into one chain: who granted it, on whose behalf, what it did. When audit season arrives, the answers to the four questions no longer come from departments filling in questionnaires — they export straight out of the audit chain (see Audit and compliance reporting) — including the over-privileged attempts the resource side refused, which are on the chain all the same. - Revocation — the kill switch: when an agent behaves oddly, the security team can revoke its grants and disable its identity at any time, and new token requests are no longer accepted. For how quickly already-issued tokens stop working, see Revocation and emergency response. The kill switch presupposes the ledger: you cannot revoke an agent you don't know exists — which is precisely why "discover" and "register" are stages at all.
Capabilities used here
The governance loop maps one-to-one onto the CISO's four questions, so it doubles as the skeleton of an internal briefing:
| The CISO asks | Stage that answers it | Capability behind it | Read more |
|---|---|---|---|
| How many agents, and who is accountable for each? | Discover · Register | First-class identity ledger, mandatory accountable people | The Agent Identity model · Register and manage your agents |
| Right now, in whose identity and on whose authorization? | Approve | Explicit delegation, consent | Consent and approval · Three access patterns |
| What can they access, and what can't they? | Approve · Review | Attenuation intersection, resource-side checks | Delegate Token and attenuation · Protect your APIs |
| How do we pull permissions back and trace it to a person? | Kill switch | Kill switch, audit_id across the whole chain | Revocation and emergency response · Audit and accountability chain |
Three sentences for the leadership team
One: every agent is on the record, nothing gets on the record without an accountable person, and ownership transfers automatically when that person leaves. Two: an agent's effective permissions are the intersection of the organization's approved boundary and its runtime grant — the intersection only gets narrower. Three: every action carries an exportable audit chain, and when something looks wrong you can revoke grants or hit the kill switch at any time.
Next steps
- Scenario: Unattended scheduled agent — what the accountability mechanism looks like for a single agent.
- Guide: Audit and compliance reporting — turn the audit chain into the report an auditor asks for.
- Concept: The Agent Identity model — the full definition of the ledger, accountable people, and the lifecycle.