On July 7, 2026, Better Auth announced it was joining Vercel. The library stays open source, the team moves to Vercel, and the announcement says what for: to invest more deeply in where auth is heading, "a future where agents act on users’ behalf and need secure, scoped, and revocable access".
It is a market signal: AI agent security is now among the reasons an auth team joins a platform. Almost all of the conversation taking shape around it (agent auth protocols, delegated tokens, scopes, revocation) shares a design assumption that I think is wrong.
The dominant model: restriction
The approach now settling in treats agent security as a problem of containment. By default, the agent is a capable, curious system with broad access: it sees the CRM, the tickets, and the customer base, and it can call tools. Fences go up around it: scoped tokens, delegated permissions, tool allowlists, instructions in the prompt ("don't reveal X", "don't access Y"), and moderation layers on the output.
It is the mental model we inherited from securing human users, and there it works reasonably well: a person with limited credentials cannot open what they are not allowed to open.
With language agents, that model breaks at one precise point: the context. An employee opens a file at the moment they need it; an LLM has the information injected into its context before it reasons, and from then on it is part of its world. Anything in the context can show up in the output: by mistake, because someone induced it, through prompt injection, or because the model found it relevant.
That yields the only hard guarantee that exists today about what an agent knows:
An agent cannot leak, misuse, or reason about information that never entered its context.
Everything else (instructions, guardrails, output filters) is probabilistic mitigation, useful and necessary at the edges. In a serious audit, "the agent is instructed not to look" is not enough.
The inversion: context is built from permission
That guarantee calls for inverting the architecture. Instead of an agent that sees everything and gets restricted afterwards, the order is reversed.
Policy first, agent second. The permission model comes before the agent: it defines which information may enter its context and which tools it may invoke, for this user, in this role, in this operation, and the agent starts inside that perimeter.
So nothing has to be hidden from the agent: what is outside the policy does not exist in its world. Call it security by nonexistence, in contrast with security by restriction.
The idea is not mine alone, and I did not publish it first. Venkat Peri, who works on agentic AI infrastructure for wealth management at Advisor360°, reached it from authorization in Designing Authorization for Production AI Agents: The Decision Gateway Pattern, in January 2026: the agent starts with a capability envelope computed before it plans, and "Unauthorized tools simply don’t exist in its world." In Beyond Lineage, Peri carries the principle to data, with a warning this thesis needs: silently removing a value from the context is not enough, because the model cannot tell a suppressed field from one that was absent from the source, and "null is an invitation to fill". What has to be missing is the content, and the gap has to stay visible: the agent has to know there is something there it cannot see, or it will make it up.
In Zarel today, nonexistence goes this far. Actions the contract does not grant the role do not exist for the model: they are not on each turn's action menu (tools from external MCP servers included) or in that user's MCP tool catalog, and records outside the role's read scope are not returned. Three things stop short of that. Entities the role cannot read still appear in the prompt, marked as having no access (the visible gap Peri asks for). If the model still names an action it was never shown, what stops it is a refusal: an ungranted write, a call to an ungranted external tool and an action the contract does not declare are all refused at the gate, which records the verdict; an ungranted read is refused without that record. And a readable record arrives whole, because fields are not yet trimmed by role on read. Nor does the runtime yet record which menu each turn was built with.
The practical difference between the two models shows up in three places.
Enforcement. In the restriction model, the barrier lives, at least partly, in the prompt and in downstream filters, layers an attacker can erode with language. In the nonexistence model, it lives in the layer that retrieves data and resolves tools: deterministic code, upstream of the model, out of persuasion's reach.
Auditability. Asked "what could the agent have seen in this conversation?", the restriction model answers with probabilities. The nonexistence model can answer with a record, as long as it keeps what each context was built from: this version of this policy, these sources, these tools. The agent's risk surface sits in its context-construction pipeline, plus what the tools that pipeline handed it can do with the values the model picks, all of which can be inspected, versioned, and reproduced.
Revocation. In the restriction model, revoking means invalidating a token the agent may already have used to read something. In the nonexistence model, the policy changes, and the agent's world changes with it the next time its context is built.
Beyond security
The same thesis has a second, organizational reading.
When an AI support assistant gets it wrong (promises a refund that does not apply, reveals another customer's data, makes up a returns policy), the usual diagnosis is "the model hallucinated". I read it differently: in many of those cases, the organization never wrote the policy the agent needed, and the agent improvised because it had nothing formal to execute.
Security by nonexistence forces the issue, because the agent's perimeter is a document: the organization's policy, explicit and versioned, on what each role may know and do in each operation. Writing it is work, but it is work the organization has owed for years, and until now it lived scattered across people's heads, outdated wikis, and habit.
The same artifact that makes the agent safe makes it correct with respect to what the organization allows. What it does not settle is the accuracy of what the model says: an agent that is authorized and compliant at every step can still assert a fact that is not in its context.
Where identity and delegation do belong
None of this makes the industry's work on identity and delegation unnecessary. At the boundaries between systems (your agent calling a third-party API, someone else's agent coming into your system) you need interoperable credentials, scopes, and revocation, and there the agent auth protocols now taking shape are the right piece. The two approaches complement each other: identity and delegation between systems, context built from policy within each one.
My objection is to the order of priorities. If the inside of the system is an agent that sees everything and has instructions to behave, a boundary protocol does not change what that agent can leak. The inside layer is an architecture decision made before you build, and it cannot be outsourced or added later.
The thesis, in falsifiable form
The concrete, refutable claim is this:
Under the same volume of adversarial attempts, an agentic system whose context and tools are built from an explicit, versioned policy will have a structurally lower incident rate (leakage, out-of-mandate action, response contrary to policy) than an equivalent system protected by instructions and filters, and that rate can be audited exactly.
It is a measurable prediction, and I have not measured it yet: that takes agents in production in front of customers. I am building on it. If you have agents in production in front of customers and counterexamples, or the same problem seen from another angle, I would like to talk.
The version of this argument for actions is in Persuasion versus governance.
Nicolás Moreno builds Zarel: governed AI operations, where the AI proposes and the contract decides.