Anthropic’s Zero Trust for AI Agents Sets the Right Test. The Bearer Token Fails It. – Hellō Blog

Anthropic’s Zero Trust for AI Agents Sets the Right Test. The Bearer Token Fails It.

June 13, 2026

Dick Hardt

Where the framework stops, and where an agent-native authorization substrate has to begin.

Anthropic’s Zero Trust for AI Agents is a detailed and well-constructed enterprise security framework, and it is worth reading in full. It gets the starting point right: agents are not chatbots. They interpret goals, choose tools, persist context across sessions, coordinate with other agents, and act. And it states the consequence plainly: traditional access controls will not stop an agent from misusing permissions it legitimately holds. That is the correct frame.

I want to take the framework seriously enough to push on it. Not because it is wrong, but because it contains the exact test that retires its own baseline recommendation.

The test the document sets for itself

The strongest idea in the document is a design test. When you evaluate any control, the guide says to ask one question:

does this make the attack impossible, or just tedious?

Anthropic is explicit that controls whose value is friction, such as extra hops, rate limits, non-standard ports, and SMS codes, degrade against an adversary with unlimited patience and near-zero per-attempt cost. The controls that survive share a pattern: cryptographic identity, credentials that cannot be exfiltrated, and network paths that do not exist rather than paths that are merely inconvenient. When in doubt, they say, prefer a control that removes a capability over one that throttles it.

That is the right test. Apply it honestly and it reaches further than the document does.

Credentials: short-lived tokens are tedious, not impossible

The credential baseline is short-lived, narrowly scoped tokens from an identity provider, hardening to mutual TLS and then to hardware-bound credentials at the top tier. The document is blunt that static API keys and shared service-account passwords should be treated as already compromised, among the first things a model-assisted attacker finds in your code.

But run the baseline through their own test. A short-lived bearer token is a throttle. It shrinks the window during which a stolen secret is useful. It does not remove the secret. The token is still a bearer credential: whoever holds it can use it. Shortening its life raises cost without closing the door. By the document’s own standard, that is tedious, not impossible.

The control that makes credential theft impossible rather than tedious is the one where there is no bearer secret to steal: proof of possession bound to a private key that never leaves the agent. The agent signs its requests. The key is non-exportable. A compromised host yields no reusable credential, because the credential was never a string. It was the ability to produce a signature. HTTP Message Signatures is exactly this, and it is the substrate AAuth is built on.

Worth noting what is absent. The document does not mention DPoP, OAuth Token Exchange, Rich Authorization Requests, or sender-constrained tokens of any kind. It reaches toward non-exfiltratable credentials only at the Advanced tier, and frames that as PKI hardening for high-assurance shops rather than as the recognition that the bearer token itself is the residual flaw at every tier below. Their principle points past their prescription. The honest endpoint of "impossible, not tedious" is to stop issuing secrets that can be carried away.

Authorization: "the agent has access" is not granular enough

Here is the larger gap, and it is not about how the credential is held. It is about what gets authorized.

The framework describes authorization as a ladder of control families: role-based access control, then attribute-based access control, then continuous authorization, paired with a lifecycle ladder of static roles, dynamic elevation, and just-in-time grants. This is a reasonable taxonomy of access-control categories. What it is not is a mechanism for authorizing a specific call.

In this model the unit of authorization is the agent and the tool. An email agent gets email permissions. A database tool gets read but not write. Attribute-based control adds context such as time of day or a risk score. But the grant is still "this agent may use this tool," possibly narrowed by coarse attributes. The actual parameters of the call are handled separately, as input validation: reject malformed or suspicious arguments before execution. Validation is a filter against bad input. It is not an authorization decision in which the specific parameters are the thing being authorized.

That distinction is the whole game for agents. "The agent has access to the payments tool" is not a useful grant. "This agent may move at most $3,000, to this payee, once, before Friday" is. The parameters are not noise to be sanitized. They are the authorization context, and they...