Access control was designed for a different actor
Role-based access control assumes an actor with a job description, a manager, and a review cycle. An agent has none of those. It chains tools, reformulates its own objectives inside a task, and can act at machine speed across systems that were never intended to be operated together.
Granting an agent a service account solves authentication and leaves authority entirely unaddressed. The question is not whether the agent can call the API. The question is whether this specific action, at this consequence level, in this context, should proceed at all.
Prompts are not policy
Instructions written into a system prompt are advisory to the model and invisible to the institution. They cannot be audited by a control function, they do not version cleanly, and they do not survive a model change.
Policy has to live outside the agent, be evaluated per request, and produce an artifact that an auditor can read.
What a control plane adds
A decision control plane evaluates each agent intent against identity, permitted tools, permitted data, consequence, reversibility, and standing authority. Requests above threshold route to a named human. Everything else executes within declared bounds.
- An institutional identity and owner for every agent
- Tool, data, spend, and rate boundaries enforced outside the agent
- Simulation of proposed actions before they reach production
- Human escalation with full context rather than a bare approval prompt
- A complete chain from intent to outcome that can be replayed
The practical starting point
The most reliable way to begin is observation. Route existing agent traffic through the control plane without enforcement, measure how often actions would have exceeded policy, and only then decide which classes of action deserve bounded autonomy.