AI Agent Access Control: What Anthropic Gets Right - and Where Enterprise Security Needs More

Anthropic recently debuted a new model for how Claude Tag, its multiplayer AI workspace product, handles agent access. The model is described for "agent identity" but the question it's actually answering is an access question: when an AI agent operates autonomously across a team, what should it be allowed to reach and on whose authority?

Their answer: the agent needs its own identity, scoped by an admin, independent of any single person in the channel. We agree. But the solution they describe is designed for a very specific engineering situation using Slack — and that distinction matters a lot if you're thinking about AI security at the infrastructure level.

Anthropic's solution encourages broad, persistent permissions by default and lacks just-in-time credential grants, running the risk of breaking a least privilege model. The solution also lacks the identity maturity and complexity required by highly connected enterprise setups involving partners or third-party agentic access. 

For an isolated Claude Tag deployment, this may be workable. But as a broader enterprise security model, it risks moving too much authorization logic into an AI workspace instead of keeping access decisions anchored in the organization's IdP, authorization server and policy layer.

What Anthropic Got Right

Anthropic’s agent identity post is honest about why per-user credential delegation stops working for autonomous, multiplayer agents. They cite two reasons:

First, agents now run procedures long after the person who triggered them has logged off. They schedule their own tasks, respond to events and operate without human supervision. The user who started the task isn't steering it anymore so their credentials shouldn't be driving it either.

Second, in a shared channel with multiple contributors, whose permissions apply? Any single choice is arbitrary and probably wrong for some share of the requests. Binding agent access to whoever happens to be present means permissions change with every person who walks in or out, and that's both unpredictable and exploitable.

Anthropic’s answer is to give Claude its own service accounts — in Slack, GitHub, a data warehouse — provisioned by an admin and scoped to the workspace or channel. Claude posts as the Claude app, opens PRs as the Claude GitHub App, queries the warehouse under a service account with no personal credentials in play. Revoking the identity ends access everywhere it was used.

This is sound thinking. The move from "act as the user" to a dedicated non-human identity is the right direction for agentic systems and it reflects what we've been arguing for in the context of API access control. But a dedicated identity only solves half the problem. For that identity to work at speed and scale, the token it generates needs to carry the right context — who the agent is, who delegated to it, what it's permitted to do — so every API downstream can make the right access decision without a separate lookup. That's exactly what Token Intelligence is designed to do.

Where the Models Diverge

Claude Tag's agent identity model is designed for one agent (Claude) operating inside one controlled environment (currently only on Slack). That context shapes every design choice and it also defines the limits of what the model addresses.

The agent is known and trusted by assumption 

Anthropic built Claude, operates it and controls its behavior. Admins aren't making a trust decision when they configure Claude Tag cause that decision was already made. The access model works because the agent on the other end is not arbitrary. The harder enterprise problem lies in what happens when the agent calling your APIs is a third-party system, a dynamically registered client or something your security team didn't build and can't inspect. This is also where the revenue and utility for AI sits in general. If organizations are aiming to roll out AI towards consumers in revenue-line services, this becomes a significant and unmanageable risk. The solution requires an access model that doesn’t assume trust.

Access is static, yet needs to be runtime-evaluated 

An admin configures what Claude can reach in a given channel. That configuration persists until someone changes it. There's no per-request evaluation of whether this specific action, at this moment, from this agent, on behalf of this user, should be allowed. Claude Tag enforces access at the channel boundary. This is a useful control, but only a coarse-grained control. Enterprise environments are more complex than a single Slack channel and that complexity demands runtime authorization: every API call in the chain gets evaluated against identity, context and risk at the moment it happens, not just at the door.

Standing privilege vs. zero standing privilege

Zero standing privilege means an agent holds no valid credentials between tasks — access is issued per interaction and expires when the task ends, leaving no live permissions to steal or misuse. Claude Tag creates persistent channel-level identities. The agent holds ongoing service accounts in connected systems and access ends only when the identity is revoked entirely. This is operationally convenient but represents standing privilege, a credential that exists and is valid between uses. Companies operating under compliance frameworks or handling sensitive data can't afford that. They need access that is scoped to the task, expires when the task is done and leaves no live credentials behind.

User and agent identity are separated, not combined

In Claude Tag's model, channels use agent identity and DMs use user credentials. There's a clean firewall, but the API layer never sees both identities at once in the channel context — there's no way to enforce policy based on who asked the agent to act. Enterprises need both identities present and verifiable throughout the request chain, so that access decisions can account for not just what the agent is allowed to do, but whether the person who triggered it had the authority to ask.

The model is proprietary to one platform. Claude Tag's access controls live inside Anthropic's infrastructure. They don't integrate with your existing IdP, API gateway or authorization server.

What this tells us about where the market is heading

There's something worth noting before getting into the implications: Anthropic is an AI company and they chose to publish a post about an access model. This signals that identity and access control are no longer just the IAM team’s problem, but are becoming a broader business concern — a prerequisite for deploying AI agents and making them workable in a trusted manner.

Agents are calling production APIs, handling sensitive data and operating with autonomy that legacy access control wasn't designed for. The Claude Tag model solves a specific problem well: how to scope a trusted, known agent's access in a product you control. That's a legitimate requirement and their design is thoughtful.

However, enterprise security teams face a much deeper challenge. They need to secure APIs from agents they didn't build, running frameworks they don't control, acting on behalf of users in ways that aren't fully predictable. For that, you need an access model that doesn't assume trust, authorization that evaluates every request rather than just the initial configuration, and credentials that disappear when the job is done.

There's no magic here. The cryptographic foundations are mature. OAuth, token-based authorization and runtime policy enforcement have been around for years. What hasn't kept pace is how organizations actually deploy them for non-human clients: tokens that carry the wrong context, policies that weren't designed for autonomous agents, authorization that stops at the perimeter. AI agents aren't a special case that requires a new security paradigm but they do demand a more rigorous approach to machine IAM than most organizations have in place. That's the gap Access and Token Intelligence is built to close.

How Curity Access Intelligence Addresses These Gaps 

Access Intelligence is built around four capabilities that directly address the enterprise security requirements Claude Tag does not cover:

• Ephemeral clients: agents authenticate per interaction with no standing privilege. Access disappears when the session ends.

• Token Intelligence: both agent and user context are carried in a single credential, so every API in the chain has what it needs to make the right decision without a separate lookup.

• Runtime authorization: every API call is evaluated against identity, context and policy at the moment it happens, not just at the perimeter.

• Human-in-the-loop controls: high-risk actions require explicit approval before an agent can proceed.

Access Intelligence works with any IdP, API gateway or agent framework - no rebuild required. Ready to secure agents you didn't build? Explore Access Intelligence.