Every agentic deployment I’ve seen follows the same pattern.
Enormous care goes into the model. Training data, prompt injection risks, hallucination mitigations. Then, almost as an afterthought, a service account gets created with whatever permissions make the demo work — and it ships.
That service account can write to production. It has no named human behind it. Nobody has documented whose authority it exercises, what the limits are, or how to revoke it when something goes wrong.
This is not a model problem. It is authorization debt.
The line that matters
An agent that drafts an email is a language problem. An agent that sends it is an authorization problem. An agent that queries a database is a language problem. An agent that modifies a record is an authorization problem.
The moment an agent moves from generating to acting, you’ve left model safety territory and entered authorization territory. Most security reviews never make this distinction.
The question to answer before you ship
When something goes wrong, a regulator won’t ask whether the model was well-calibrated. They’ll ask: who authorized this action, and why?
If you can’t point to a named principal, explicit limits, and a documented revocation path — you haven’t secured the agent. You’ve just hoped the model behaves.
Agent security isn’t a new discipline. It’s authorization applied to a faster, less forgiving class of actor.
The question hasn’t changed.
Who can act on whose behalf?
Delegated Authority is a monthly essay series on how enterprises govern authority across humans, software, and AI agents.