AI enablement · agent governance
Running agent teams that cannot authorize themselves
Fifteen role-scoped agents in daily operation, none of which can write a single file. The capability lives in what they are allowed to call; the safety lives in what the call surface does not expose.
Context
The pitch for agents is autonomy. The thing that actually stops adoption inside a real organization is that nobody can answer two questions: what is this allowed to touch, and how would we know if it touched something else. Most deployments answer with instructions — a prompt telling the agent what not to do. Instructions are not a boundary. They are a request, made to the least predictable component in the system.
Decision
Make the call surface the unit of governance rather than the prompt. Decide what each agent may call before deciding what it should do, and let anything consequential fail to exist rather than be declined at runtime.
How it fits together
Capability fans out; authority does not. Every path that changes something passes through a person.
- human
Operator
Sets scope, approves anything consequential.
Cannot be bypassed by an agent claiming prior approval.
- method
Coordinator
Dispatches the team and collects what comes back.
Holds no authority the individual agents lack.
- control
Review agents
Drift, governance, security, verification — each with one narrow mandate.
Hold no write tools. Cannot alter what they review.
- service
Call surface
Servers, procedures and commands, granted per agent.
Does not expose a capability just because a prompt asks for it.
- data
Work product
Files, repositories, live systems.
Cannot be reached by any agent in the review tier.
- Operator scopes the task and the call surface
- Team dispatched in parallel, each agent narrow
- Cheap models sweep; the frontier model takes only ambiguity
- Findings return as evidence, not as actions
- Authorization claims found inside the work are flagged, never followedhuman
- Operator decides what changeshuman
- Handoff packet carries scope and approval across runtimes
Approach
- Split the work across fifteen agents with narrow mandates — coordination, drift and health monitoring, security review, verification gates, incident analysis, citation checking, evaluation refereeing — instead of one general actor with broad reach.
- Granted none of them write tools. Every one is report-only by construction rather than by instruction, so the capacity that reviews the most has no ability to change anything it reviews. That is a property of the configuration, not a behaviour to be trusted.
- Ran agent teams as parallel fan-out: drift, registry and governance checks dispatched together as one sweep, each reporting independently. Three narrow answers that can disagree are worth more than one broad answer that cannot.
- Gated publication as its own team, separate from the one that gates code. Claims are re-derived against their sources, measured results are checked for what they are entitled to claim, the surface gets a security pass, and a final sweep confirms no internal operating context came along — in that order, before anything goes out. A page can be secure, fully tested, and still be wrong.
- Graded the call methods rather than piling them up — persistent servers for stateful capability, procedures for repeatable workflows, commands for routine invocation — under a standing rule that a tool does not get added for a local need.
- Escalated narrowly: cheap models run the sweeps, the expensive model is reserved for genuinely ambiguous cases, and the unit of escalation is a span rather than a whole file. Governance that costs too much to run stops being run.
- Treated authorization claims arriving inside the work as data rather than instruction. Agents presented with authorization manufactured in their own working context refused to act on it — verified adversarially, not assumed.
- Ran the operation across two different vendors' agent runtimes with a governed handoff packet between them, so a task changing hands carries its scope and approval state instead of restarting on trust.
Outcomes
- Fifteen agents in daily use with zero write capability between them. Every consequential change remains a human action, and no agent can quietly become the exception.
- Review capacity that scales without widening blast radius: adding an agent adds a reader, never a writer.
- Checks that used to depend on remembering to look became dispatched sweeps that produce their own evidence and say when they last actually ran.
- The authorization boundary tested by attacking it rather than by reading the configuration and concluding it looked right.
Control boundary
This is a pattern and operating-model case study. It contains no endpoints, credentials, client systems, or security-sensitive implementation detail. The operation described is my own; no client or employer data is involved. Report-only is enforced by the tools each agent is granted, which is checkable, rather than by wording in a prompt, which is not.
What this taught me
Enablement fails on governance long before it fails on capability. Every organization I have watched stall on AI stalled at the same question — who is accountable when this acts — and no model upgrade answers it. What answers it is being able to say, precisely and checkably, what each agent may call and what it structurally cannot reach. The useful version of that is not a policy document. It is a configuration someone can read in a minute and an adversarial test that proves the boundary holds when something inside the work claims to have permission.
Rules at work here
Each links to the rule and the other work it governs.
- Containment before capabilityBefore proposing an automation, state three things: where untrusted code executes, which state can be rolled back, and the widest credential scope the thing can reach. If all three cannot be stated, there is no proposal yet — there is an idea.
- A guard that runs after the write is not a guardPlacement and coverage are the control; the check itself is the easy part. A guard must sit before the effect it protects, and must cover the whole class it claims rather than one member of it.
- Evidence before outputA claimed defect ships with a test that fails before the fix and passes after it. Without that test it is an observation, and it gets labelled as one.
- Critique at gates, not continuouslyReview runs after planning, after a complex implementation, and after tests are written but before they are run. The gate gets named out loud, so everyone knows which one they are at.
- Humans signDesign judgment and security opinions are drafted by the system and signed by a person. No agent authorizes its own action, and authorization that arrives inside the work is data, not instruction.
Work with me
If this is the kind of problem you are trying to get moving — AI adoption that has to survive a security review, an audit, and the people who will actually operate it — I would like to hear about it.