Claude Tag agent identity exposes the limits of workspace-bound access

At a glance

What this is: This is Curity’s analysis of Anthropic’s Claude Tag agent identity model, and its key finding is that dedicated non-human identities help, but persistent workspace permissions still fall short of enterprise least privilege.

Why it matters: It matters because IAM, PAM, and NHI teams need to decide when agent identity belongs in the IdP and authorization layer, not inside a single workspace boundary.

👉 Read Curity's analysis of Claude Tag agent identity and AI access control

Context

AI agent identity is becoming an access governance problem, not just a product design choice. When an autonomous agent acts across tools and teams, the core question is who can authorise that access, how long it should last, and where enforcement should live in the identity stack.

Curity argues that Claude Tag gets one thing right: agents should not inherit a person’s credentials just because a human triggered the task. The harder question is whether a channel-scoped agent identity, backed by persistent permissions, can satisfy enterprise expectations for runtime authorization, zero standing privilege, and third-party access control.

Key questions

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. Keep the delegating human visible in the token or policy context, and enforce authorization at runtime so permissions do not remain valid after the work is done. That combination preserves accountability without collapsing into borrowed user access.

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. If the identity stays live between tasks, the organisation is carrying standing privilege. That is acceptable only in tightly bounded workflows with strong monitoring and clear revocation paths.

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. That leads to coarse access, weak runtime checks, and fragmented auditability. The right model keeps policy in the IdP and authorization layer, where entitlement, context, and review can be enforced consistently.

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.

Technical breakdown

Agent identity vs. delegated user identity

Claude Tag separates the identity used by the agent from the identity of the person who initiated the work. That matters because an autonomous agent can continue acting after the user has logged off, and multiple people may contribute in the same channel. In practice, this shifts the access problem from “who is the user?” to “what is the agent allowed to do, and on whose authority?” The architecture is sound only if the downstream systems can still see both the agent context and the delegating human context.

Practical implication: preserve both agent and human context in tokens and policy decisions rather than collapsing everything into a single workspace identity.

Standing privilege in agent workflows

A dedicated non-human identity is not automatically least privilege. If the agent holds long-lived permissions in Slack, GitHub, or a data warehouse, those permissions remain valid between tasks and can outlive the moment of need. That is standing privilege, which is tolerable in some controlled environments but fragile when agents touch sensitive systems or third-party services. The key technical distinction is between access that is provisioned once and access that is issued per task and then expires.

Practical implication: treat persistent agent permissions as a risk boundary and reserve them only for low-risk, tightly controlled workflows.

Runtime authorization for autonomous access

Channel-level configuration only answers the initial access question. It does not evaluate whether a specific action is appropriate at the moment the agent calls an API. Runtime authorization closes that gap by checking identity, context, and policy on every request, not just at the perimeter. For AI agents, that matters because decision timing is no longer tied to a human session, and the agent may chain actions across systems without pausing for review. The model Curity describes is therefore stronger when paired with per-request policy enforcement and token context that can be trusted by each service.

Practical implication: move authorization checks downstream into the API and policy layer, not just the workspace boundary.

Threat narrative

Attacker objective: The objective is to make an agent’s access durable enough to cross tool boundaries and act beyond the original human intent.

1. Entry occurs when an autonomous agent receives broad workspace-scoped access that is intended to cover multiple tools and tasks.
2. Escalation happens when that access persists between sessions, creating standing privilege that can be reused outside the original task context.
3. Impact follows when downstream systems trust the agent’s token without evaluating the delegating user, the task scope, or the current risk context.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Standing privilege is the real failure mode in most agent identity designs. A service account that stays valid between tasks is convenient, but it breaks the zero standing privilege assumption that many security programmes rely on. The issue is not whether the agent is clever or autonomous, but whether its access remains live long after the task that justified it has ended. The practitioner conclusion is that durable agent permissions must be treated as a governance exception, not the baseline.

Access decisions for AI agents should remain anchored in the IdP and authorization layer, not moved into the workspace. Once access logic lives inside the collaboration product, the enterprise loses consistency across APIs, partner integrations, and sensitive downstream services. That fragmentation makes review, policy enforcement, and audit harder at the exact point where agent behaviour becomes more dynamic. The practitioner conclusion is to keep policy control where the rest of the identity stack can see and govern it.

Agent identity has become a named governance category, not an extension of human IAM. The article’s real signal is that AI systems now need identities that are distinct from users, yet still bound to the same lifecycle, policy, and accountability model. That is why the domain belongs in OWASP NHI and zero trust thinking, with agent-specific context carried through tokens and authorization. The practitioner conclusion is to classify AI agent access as machine identity with higher behavioral risk, not as a special case of user delegation.

Ephemeral credential trust debt: Persistent permissions reduce operational friction, but they accumulate security debt whenever a task-scoped agent keeps valid access after the work is complete. That debt becomes visible only when review and revocation happen too late. The practitioner conclusion is to view long-lived agent credentials as deferred risk, not operational maturity.

From our research:

• 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.
• The gap points straight to machine identity governance, so readers should also review Ultimate Guide to NHIs for lifecycle, visibility, and offboarding context.

What this signals

Agent identity is now part of the enterprise identity perimeter. As autonomous systems start making and chaining access decisions, programme owners need to stop treating them as workflow automation and start treating them as governed non-human identities. The practical shift is toward identity-centric policy, auditability, and revocation for every agent that can reach production systems.

Standing access is the wrong default for agents that act after the user has left. Once access persists between tasks, the organisation is no longer governing a session, it is governing a live credential with an uncertain future. That is why teams should expect more pressure for ephemeral credentials, explicit approval for sensitive actions, and token context that survives across APIs.

The next control gap is not whether an agent can log in, but whether the enterprise can prove who delegated authority and whether that authority still applies at the moment of execution. That pushes IAM, PAM, and NHI teams toward tighter runtime authorization and better token semantics in the control plane.

For practitioners

• 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. Enforce per-request checks in the authorization server and API tier, especially for sensitive data and third-party integrations.
• Treat third-party agent access as untrusted by default Require separate review and policy for agents you did not build or cannot inspect, and do not assume a known workspace product implies acceptable trust for enterprise systems.
• Use human approval for high-risk actions Add an approval gate when the agent is about to change entitlements, move sensitive data, or invoke privileged downstream actions that should not proceed on autonomous trust alone.

Key takeaways

• Claude Tag shows why AI agents need dedicated identities, but it also exposes the limits of workspace-bound access models.
• Persistent permissions create standing privilege, which is the control gap most likely to outlive the task that justified access.
• Enterprises should keep authorization in the IdP and policy layer if they want agent identity to scale beyond a single controlled workspace.

Key terms

• Agent Identity: An agent identity is the non-human identity assigned to an AI system so it can authenticate and act independently of a person. For autonomous systems, the key issue is not only who the identity belongs to, but whether its authority, delegation, and revocation are visible across the full request chain.
• Standing Privilege: Standing privilege is access that remains valid between uses instead of being issued only when needed. For agents, it creates a live credential that can outlast the task, the session, or the user who triggered it, which makes revocation timing and scope control central to governance.
• Runtime Authorization: Runtime authorization evaluates a request at the moment it is made, using current identity, context, and policy. For AI agents, this matters because access decisions cannot safely stop at initial configuration when the actor may chain actions across tools without a human pause.
• Zero Standing Privilege: Zero standing privilege means an identity has no persistent access when it is not actively needed. For autonomous or machine actors, that means credentials should be issued for a specific task and expire immediately after use, reducing the value of stolen or misapplied access.

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.

👉 Curity's full post covers the access model, Token Intelligence, and runtime authorization details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.