Anthropic Is Right About Least Agency. The Remaining Boundary Is the Exact Business Action.

INDUSTRY ANALYSIS · AI SECURITY

By Mark Rogge, CEO of EnforceAuth | 6 min read | For CISOs, IAM leaders, and platform teams deploying Claude and other enterprise agents

Anthropic has published Zero Trust for AI Agents — one of the most serious, most usable agent-security frameworks anyone has put in front of enterprise security leaders. It adapts the discipline that reshaped network security to systems that now interpret goals, chain tools, and act at machine speed. Its organizing principle is least agency: grant an agent the narrowest capability that can complete the assigned task, and no more. Read it. Adopt it. It is right.

I want to be precise about where I agree, because the useful part of this conversation starts exactly where the framework ends. Anthropic is not hand-waving. It ships real controls, and it names the real problem in a single sentence:

"Traditional access controls won't prevent agents from misusing legitimate permissions." — Anthropic, Zero Trust for AI Agents

That is the whole opening, stated by the vendor drawing the baseline. The permission is legitimate. The identity is authenticated. The tool is allow-listed. And the framework itself concedes that none of that decides whether the specific thing the agent is about to do should happen. Hold onto that sentence.

Anthropic drew the right line

Look at what Claude Enterprise and Cowork actually give a security team, and you will see a mature baseline, not marketing. Identity through SAML or OIDC, with SCIM and role-based access. Connector allowlists at the organization and role level. Restrictions on individual actions inside a connector — permit reads or drafts while disabling sends and deletes. Isolated execution, credentials injected through a reverse proxy, mandatory egress controls. Per-invocation telemetry over OpenTelemetry that captures the MCP server, the tool, the parameters, the outcome, the user identity, and the session. Organization-wide and role-specific shutdown.

This is least agency implemented well: cryptographically rooted identity, deny-by-default tool access, blast-radius containment, and observability. "Per-tool, per-action approval" is about to become standard buyer language, and it should. If you are deploying agents without this baseline, close this tab and go build it first.

Where the line points next

Least agency answers: which capabilities may this agent hold? The question underneath it — the one that determines whether you have a control or a liability — is different:

A tool may be available and an action verb may be enabled. But is this exact action — with these parameters, against this resource, for this tenant and this business purpose — authorized right now?

Capability availability is not transaction authorization. This is the Authorization Gap, and agents widen it dramatically, because an agent will happily exercise every capability it legitimately holds, in combinations no one reviewed, faster than anyone can watch. An agent can pass every least-agency check you configured and still:

• Read a record that belongs to a different customer — same tool, same permission, wrong tenant.
• Send approved information to an unapproved recipient — 'send' is enabled; this destination should not be.
• Move an amount that exceeds a transaction limit — the payment tool is permitted; this figure requires dual approval.
• Act outside the task it was delegated to do — the capability was granted for one purpose and is being used for another.
• Complete an operation after its authorization has expired — nothing at the tool layer re-checks the clock.

None of those are least-agency failures. The capability was, by design, appropriate. Each is a per-transaction authorization decision that no allowlist, no action toggle, and no telemetry stream can make on your behalf. Telemetry tells you it happened. Authorization decides whether it happens at all.

This is a policy decision, and it has to be deterministic

You cannot ask the model to police this. A probabilistic system cannot enforce a deterministic boundary — 'usually denies the cross-tenant read' is not a security control. The decision has to be external to the agent, evaluated the same way every time, and provable after the fact.

That is what EnforceAuth is built for. The identity, agent identity, MCP server, tool, parameters, and session context that Anthropic already exposes become the inputs to a deterministic policy decision — authored as policy-as-code in OPA/Rego, versioned in git, tested in CI, and evaluated at the moment the agent acts. The policy incorporates the things a tool allowlist structurally cannot see: resource ownership, the delegation chain, data classification, transaction value, approval state, and separation of duties. Same action, different tenant or different amount, different answer. Default deny. Every decision emits a reason.

And crucially, the same policy has to hold wherever the action travels — through an MCP connector, through a direct API call, and at the resource itself. An agent that is blocked at the gateway but can reach the same resource by another path is not governed; it is inconvenienced. One policy, evaluated consistently across every path, is the difference.

What this means if you're deploying Claude

The architecture is complementary, and it is simple to draw:

IdP → Claude / Cowork → MCP connector → EnforceAuth policy decision point → protected application or resource

Anthropic authenticates the identity, scopes the capability, isolates execution, and emits the telemetry. EnforceAuth takes that same context and returns an allow-or-deny decision for the specific business action — before it commits, with a logged reason your auditors can query. Least agency keeps the blast radius small. Least-authorized business action keeps the wrong transaction from ever firing inside that radius. You want both. They are not the same control, and one does not substitute for the other.

This is not a niche concern that arrives later. Non-human identities already outnumber humans in most enterprises by roughly 82 to 1, and every one of those agents is a caller that can hold a legitimate permission and still make a decision that should have been denied. Anthropic has handed the industry a baseline that validates identity, least privilege, and per-action telemetry. The next control up the stack — the one that decides the exact transaction — is authorization. That is the boundary we build on.

If you're mapping this against a Claude deployment, our five-layer reference architecture for continuous authorization is the place to start, and we're happy to walk your team through the Claude-specific version — IdP to connector to policy decision point to resource — deny scenarios included. Anthropic is right about least agency. The remaining boundary is the exact business action.