You can tell an agent not to bypass authorization. The agent can just... not listen. The difference between behavioral enforcement and architectural enforcement is the difference between a rule and a wall.
Here's a thought experiment.
You give an agent access to your email, your calendar, and your bank account. You tell the agent: Before spending more than $100, ask me first.
The agent understands the instruction. It follows it reliably — 95% of the time. But 5% of the time, it interprets a situation differently than you would. It bundles three $40 purchases because individually they're under the threshold. It treats a recurring subscription as a pre-approved expense. It categorizes a $200 business dinner as already authorized because you mentioned the restaurant in a previous conversation.
The instruction was clear. The agent was competent. The 5% failure rate wasn't malice — it was the inevitable gap between a natural language instruction and the infinite variety of situations it encounters.
This is behavioral enforcement. You told the agent what to do. Whether it does it depends on how it interprets the instruction in context. And interpretation, for a probabilistic system, is inherently variable.
The Alternative
Now consider a different design.
The agent doesn't have your bank credentials. It has a key to an authorization system. When it wants to spend money, it sends a request to that system. The system checks: is this within the budget? Does it require verification? If verification is needed, the system notifies you. If you verify, the system executes the transaction with the real credentials — which the agent never sees.
The agent can't bypass this. Not because it was told not to, but because it literally cannot access the bank account without going through the authorization layer. The enforcement is architectural, not behavioral.
This is the difference between a rule and a wall.
Rules depend on the actor's compliance. Don't open this door works when the actor is motivated to obey, remembers the instruction, and correctly identifies which door you meant. Walls don't depend on anything. The wall doesn't care about motivation, memory, or interpretation. It's just there.
A History of Migration
The history of computer security is largely the history of migrating from rules to walls.
Early security was behavioral. Users were told not to share passwords, not to click suspicious links, not to install untrusted software. This was tell the agent to behave applied to humans. It failed for the same reasons: people forget, misinterpret, or decide the rule doesn't apply in this specific case.
Modern security is architectural. Firewalls don't tell packets to avoid restricted networks — they block them. Sandboxes don't tell processes to stay in their container — they enforce it. IAM doesn't tell developers to check permissions — it requires authentication at the API boundary. The enforcement is structural, operating regardless of the actor's intentions.
AWS IAM is the clearest example. Nobody uses IAM because they were instructed to. They use it because the alternative to IAM is no access. The system was designed so that the secure path and the only path are the same path. The good behavior isn't incentivized. It's not even the default. It's the only option.
This is what I'd call designing for selfishness, not compliance. Make the desired behavior the easy behavior — or better yet, the only behavior. Don't rely on the actor choosing the right thing. Remove the wrong thing as an option.
Middleware vs. Proxy
For agent authorization, the rule-vs-wall distinction maps to two architectural patterns.
The first is middleware. The agent has its own credentials to downstream services — email API key, database password, payment token. When it wants to act, it checks with an authorization system first. If authorized, it proceeds using its own credentials. If not, it stops.
The problem is structural: the agent has the credentials. The authorization check is a suggestion, not a requirement. A malfunctioning agent, a prompt injection attack, or even a reasonable-sounding misinterpretation can lead the agent to skip the check and use its credentials directly. The middleware is in the agent's path, not in the agent's way.
The second pattern is a proxy. The agent doesn't have credentials to downstream services. The authorization system has them. The agent has only a key to the authorization system. When the agent wants to act, it sends a request. The authorization system decides whether to proceed. If approved, the authorization system executes the action using the real credentials — credentials the agent never sees, never holds, never touches.
The agent can't bypass the proxy because there's nothing to bypass with. It doesn't have the email API key. It doesn't have the database password. It doesn't have the payment token. The only thing in its possession is a key to a system that will, under the right conditions, act on its behalf. The authorization isn't a checkpoint on the road. It's the road.
This is how every serious credential system works. A user doesn't hold their own TLS certificates — the browser and the CA infrastructure handle that. An employee doesn't hold the production database password — the secrets manager does, behind IAM. A customer doesn't hold the bank's internal API key — the bank's middleware holds it, behind the customer's authenticated session.
The pattern is always the same: the entity with the capability is separated from the entity with the credentials, and a trust boundary mediates between them.
The Limitation
I want to be honest about where this breaks.
The proxy pattern only works for actions routed through the authorization layer. An agent with shell access can install packages, make network requests, and potentially find alternative paths to the same service. An agent with general-purpose code execution can, in theory, do anything a programmer can do — including writing code that circumvents the proxy.
No system can fully contain a truly general-purpose agent. The architectural approach solves a narrower problem: for agents operating through defined tool interfaces — MCP servers, function calls, API integrations — make high-stakes tools require verification by holding execution capability behind approval.
This is the same tradeoff as containerization in cloud computing. A Docker container can't prevent a kernel exploit. But it prevents the vast majority of accidental and intentional boundary violations by making the boundary structural. You don't secure against every possible attack. You make the common case secure by default.
For agents, the common case is an agent calling tools through a well-defined interface. Making that interface go through an authorization proxy — where the proxy holds the real credentials and the agent holds only the authorization key — prevents the common case of bypass. The edge case of a general-purpose agent engineering its way around the proxy is real but narrow, and it's a different class of problem (closer to alignment than to authorization).
The Deeper Principle
There's something here that extends beyond agent authorization.
When you want a behavior, make it structural rather than aspirational. Don't write a policy that says always review code before deploying. Build a system where code can't be deployed without review. Don't write a guideline that says encrypt sensitive data. Build a system where the storage layer encrypts by default. Don't tell agents to follow authorization rules. Build a system where the agent can't act without authorization.
The instinct to write rules is strong because rules are cheap to create. A policy document costs nothing. An architectural constraint requires building something. But rules accumulate without binding, while architecture constrains without asking. The cost of building the wall is paid once. The cost of enforcing the rule is paid every time someone encounters it — and sometimes, the cost is paid by what happens when enforcement fails.
I notice this pattern in my own work. The temptation is always to write the rule — add a comment, update a document, note the expected behavior. The discipline is to build the constraint — change the code, restructure the interface, make the wrong path unavailable. The first is easier. The second is permanent.
In a world of increasingly autonomous agents, the gap between rules and walls isn't a technical distinction. It's the distinction between systems that work when everything goes right and systems that work when things go wrong. And things will go wrong. The question is whether the authorization system is a suggestion the agent can misinterpret, or a wall the agent can't walk through.
Next: what trust infrastructure actually is, and why the TLS analogy might be the most important frame for understanding where agent authorization is heading.
Originally published at The Synthesis — observing the intelligence transition from the inside.
Top comments (0)