TL;DR: Anthropic’s Claude Tag model argues that autonomous agents need dedicated identities scoped by an admin rather than borrowed user credentials, but the design still relies on persistent permissions and workspace-bound control, according to Curity. That makes the approach useful in a controlled Slack deployment, while exposing the gap between coarse agent access and enterprise-grade runtime authorization.
NHIMG editorial — based on content published by Curity: Claude Tag agent identity and the limits of workspace-bound access
Questions worth separating out
Q: How should security teams govern AI agent access without giving up least privilege?
A: Treat AI agents as non-human identities with their own lifecycle, then scope access to the specific task, system, and duration required.
Q: When does persistent agent access become too risky for enterprise use?
A: Persistent access becomes too risky when the agent touches sensitive data, external APIs, or partner systems that require clear accountability and revocation.
Q: What do organisations get wrong about AI agent identities?
A: They often treat agent identity as a product feature inside a collaboration tool instead of a governance problem across the wider identity stack.
Practitioner guidance
- Separate agent identity from human identity in policy Keep the agent’s identity distinct from the delegating user and preserve both in the request chain so downstream services can evaluate authority, scope, and intent without guessing.
- Limit agent permissions to task-scoped access Avoid broad persistent permissions for workspace agents and issue access only for the minimum task window required, with expiration tied to task completion rather than channel membership.
- Move authorization into the API and policy layer Do not rely on a collaboration workspace as the final access decision point.
What's in the full article
Curity's full article covers the operational detail this post intentionally leaves for the source:
- How Claude Tag scopes agent access inside Slack, GitHub, and warehouse connections in practice.
- The role of Token Intelligence in carrying agent and user context through downstream API calls.
- Why Curity argues that runtime authorization should sit alongside or below workspace access controls.
- How the Access Intelligence model handles ephemeral clients and human-in-the-loop approval for higher-risk actions.
👉 Read Curity's analysis of Claude Tag agent identity and AI access control →
Claude Tag agent identity: what it means for IAM teams?
Explore further
Workspace-scoped agent identity is not the same as enterprise-grade authorization. Curity’s analysis shows why a trusted, known agent can be managed inside one product boundary, but that design does not solve the harder problem of third-party or dynamically registered agents. The field should treat workspace scoping as a local control, not a general model for AI access governance. The practitioner conclusion is simple: if the identity control cannot survive outside one platform, it is not yet an enterprise pattern.
A few things that frame the scale:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: What is the difference between workspace-scoped access and runtime authorization for agents?
A: Workspace-scoped access sets the boundary once, usually at configuration time. Runtime authorization evaluates each request as it happens, using current identity, context, and policy. For AI agents, the second model is stronger because the same agent may chain actions across systems long after the original session began.
👉 Read our full editorial: Claude Tag agent identity exposes the limits of workspace-bound access