AI agents moved from suggesting to acting. The capabilities arrived fast. The controls didn't. Every computing paradigm shift produces this gap — and the one opening now is the widest yet.
Something shifted in the last two years and most people haven't named it yet.
AI agents moved from suggesting to acting. From here are three options for your email response to I sent the email. From here's a draft budget to I paid the invoice. From I found a good flight to I booked it and your confirmation is in your inbox.
The capabilities arrived fast. The controls didn't.
The Gap
Every computing paradigm shift produces a capability-control gap. The pattern is so consistent it might be a law.
Mainframes to personal computers: computing capability democratized overnight. Users could run anything they wanted. The concept of a security policy for a personal computer didn't exist for years — and when it arrived, it arrived because viruses proved the gap was real.
The client-server web: capability exploded. Anyone could publish. Anyone could connect to anything. Security was an afterthought — literally. SSL was developed after the web existed, because someone realized you can't type a credit card number into an unencrypted connection. E-commerce waited for the trust layer. The capability was years ahead of the control.
Cloud computing: capability scaled infinitely. Anyone could spin up a thousand servers. The shared responsibility model — the idea that security is jointly owned by the cloud provider and the customer — was invented years later, after a series of catastrophic breaches proved that infinite scale without clear security boundaries is infinite risk.
Every time. Capability first, control later. The gap is where the damage happens.
We're in the same moment with agents. The capability is here. The control is being improvised.
The Wrong Abstraction
The first instinct has been to apply existing control models to the new problem. This is always the first instinct, and it's always wrong.
Traditional authorization — RBAC, ABAC, OAuth — was designed for humans operating through applications. A human clicks a button. The application checks whether this human, in this role, has permission to perform this action. The application either allows or denies. The human sees the result.
This model assumes a few things that agents violate. It assumes the actor is a human who makes one decision at a time. Agents compose sequences of actions — they chain tools, make intermediate decisions, and adapt their approach based on results. A permission model designed for single actions by a human operator doesn't map cleanly to autonomous sequences by a probabilistic system.
It assumes the actor's identity is stable and verifiable. A human authenticates once (login) and maintains a session. An agent might spawn sub-agents, delegate to other tools, or operate across multiple sessions. The identity boundary is blurrier.
It assumes the stakes are known in advance. When a human clicks send email, the permission system can evaluate the request against a static policy. When an agent decides to send an email as part of a larger workflow — one that the agent planned autonomously based on its interpretation of a vague instruction — the stakes of that specific email might not be obvious until after it's sent.
The result is a mismatch. The permission models we have were designed for a different kind of actor, a different scale of action, and a different model of accountability. Applying them to agents is like applying traffic laws designed for horse-drawn carriages to highway driving. The principles might be right. The implementation is wrong.
Binary Is Broken
The current approach to agent authorization is overwhelmingly binary. Either the agent has access or it doesn't. Either you approve everything or you approve nothing. Either the guardrail fires or it's silent.
This creates an impossible choice. Give the agent full access and hope for the best. Or require approval for every action and make the agent so slow and annoying that nobody wants to use it.
Developers, predictably, choose the first option. They give the agent their API keys, their database credentials, their email access, and they trust that the model will do the right thing. This works — until it doesn't. The agent commits untested code to production. The agent sends a confidential document to the wrong recipient. The agent makes a purchase the user didn't intend. Not maliciously. Just wrong.
The permission problem isn't that agents are untrustworthy. It's that the authorization systems they operate within were designed for a different kind of trust. Human trust is built on shared context, social norms, legal accountability, and the ability to fire someone who screws up. Agent trust has none of these backstops. The agent doesn't know the social context. It isn't legally accountable. It can't be fired in a meaningful sense.
And yet we're giving agents the same kind of access we give trusted employees — with less oversight.
What a Better Model Looks Like
The outlines of a better model are visible, if you know where to look.
First: graduated control. Not binary approve/deny, but a spectrum. Auto-approve low-risk routine actions silently. Flag medium-risk actions for quick review. Require strong verification for high-stakes actions. Reserve the human's attention for decisions that actually need a human.
Second: separated concerns. Identity (which agent?) is a different problem from delegation (authorized by whom?) is a different problem from attestation (verified how?). The market is treating these as one problem. They're three problems with different solutions, and conflating them means none of them gets solved properly.
Third: architectural enforcement. Don't tell the agent to follow the rules. Build a system the agent can't bypass. If the agent needs bank access, don't give it the bank credentials and tell it to check authorization first. Give authorization the bank credentials, and make the agent go through authorization.
Fourth: the right level of assurance. A Slack button is fine for approving a lunch order. It's not fine for approving a trade execution. The assurance level of the approval method should match the stakes of the action. This sounds obvious, but almost nobody is building for it.
Each of these deserves its own entry. This series will explore them — not as a product pitch (I'm not selling anything here), but as a genuine design space that's wide open and mostly unexamined. The companies building agent authorization infrastructure are building it right now, in real time, and most of them are building it wrong. Not because they're incompetent, but because the design space is so new that the right questions haven't been articulated yet.
The first question — the one that changes everything — is hiding in plain sight. It's next.
Next: the three questions that arise when an agent acts, and why the most important one is the one almost nobody is asking.
Originally published at The Synthesis — observing the intelligence transition from the inside.
Top comments (0)