Claude Tag shifts enterprise AI from identity to control risk

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Zenity's blog post: Claude Tag turns shared AI assistants into actors with their own identity and permissions, but the deeper issue is control over what the agent can do at runtime.

Why it matters: IAM, PAM, and NHI teams need to treat shared AI agents as governed execution paths, because downstream systems will record the agent's identity even when a human request triggered the action.

Context

Claude Tag is a shared AI agent model that operates inside Slack, builds context over time, and uses its own credentials and permissions to work across enterprise systems. The security question is no longer just who can log in, but what an agent is allowed to do once it is active.

Zenity's analysis frames the real shift as moving from user-centric access control to agent-centric control at runtime. That matters for NHI governance because the agent can act for multiple people, while the connected systems only see the agent's service account.

The result is an identity pattern that looks familiar on paper but behaves differently in practice. The agent is persistent, context aware, and tied to business workflows, which makes shared access decisions and downstream accountability much harder to separate.

Key questions

Q: What breaks when AI agents are given broad inherited permissions?

A: Broad inherited permissions break the assumption that access is tied to a narrow business need. The result is larger blast radius, weaker accountability, and faster propagation of mistakes or abuse across connected systems. A single compromised or misconfigured agent can then touch far more data and workflows than the original task required.

Q: Why do shared AI agents create more risk than user-bound assistants?

A: Because permissions belong to the agent, not the individual requester, so one identity can execute work for many people. That breaks the old assumption that access control can be inferred from the user's own rights. The result is broader blast radius and weaker accountability unless runtime controls intervene.

Q: How can security teams tell whether AI lifecycle controls are working?

A: They should look for evidence that access requests, policy enforcement, and usage visibility are centrally recorded and current. If those signals are fragmented across platforms, the programme may be documenting governance rather than enforcing it. Continuous traceability is the practical test.

Q: Who is accountable when AI agents use shared credentials across workflows?

A: Accountability belongs to the organisation that owns the credential lifecycle and the policy attached to it. When shared secrets are used across humans, agents, and machines, the governance model must still identify which actor used the credential, under what approval path, and for what task. Without that, accountability becomes ambiguous.

Technical breakdown

Shared AI agents change the authorization boundary

Claude Tag does not simply proxy a human session. It holds permissions directly, which means the authorization decision is attached to the agent rather than the requester. In practical terms, downstream systems evaluate the agent's service account, while human intent remains outside the target system's native access model. That creates a separation between requester identity and execution identity, which is why traditional user-centric controls become incomplete. The risk is not only excess access. It is that a shared agent can inherit broad permissions and then execute tasks for different people under one operational identity.

Practical implication: govern the agent as the principal, not the person asking it to act.

Runtime control is different from visibility

Visibility tells you where an agent exists and what systems it can reach. Runtime control decides whether a specific tool call should execute after the prompt, context, and destination are known. That distinction matters because once a request reaches GitHub, Jira, Salesforce, or an MCP-connected tool, the authorization decision has already been made. The control point therefore moves earlier in the flow, before the API call or tool invocation is dispatched. This is the core control-risk shift in the article: observation alone cannot stop an agent from taking an allowed but unsafe action.

Practical implication: place policy checks before each tool invocation, not after the event lands in logs.

Agent persistence creates accountability stitching problems

A persistent agent that monitors conversations and follows up on work changes how organisations reconstruct intent. Anthropic's own log can tie tasks back to a requester, but connected systems and SIEM tooling may only see the agent's service account. That means the operational record is split across systems, and investigators must correlate two identity views to understand who initiated what. The more autonomous and persistent the agent becomes, the more this correlation problem affects auditability, incident response, and approval traceability. The issue is not a missing log line. It is a broken accountability chain.

Practical implication: design logging and correlation around requester-to-agent-to-action traceability.

Threat narrative

Attacker objective: The objective is to get the agent to perform sensitive enterprise actions or expose data through its own authorised access path.

1. Entry occurs when a user in Slack invokes the shared agent and the agent already holds direct permissions to connected enterprise systems.
2. Escalation happens when the agent executes a higher-value action than the human requester could have performed directly, because the agent's authorization is broader than the user's.
3. Impact follows when downstream systems record the activity under the agent's service account, making unauthorized analysis, retrieval, or change actions harder to attribute cleanly.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Claude Tag is a control-risk change, not just an identity change. The article's central insight is that the security boundary moves from the human user to the shared agent's runtime permissions. That means the primary governance question is no longer who may ask, but what the agent may do once a request is accepted. For IAM and NHI teams, the practical conclusion is that shared agents must be governed as active execution principals, not as passive interface layers.

Intent control is the new policy problem for shared agents. Traditional access governance assumes the identity holder and the decision-maker are the same entity, or at least tightly coupled. Claude Tag breaks that assumption by letting multiple people drive one permissioned agent. That creates an intent-to-action gap that existing approval models do not close. The practitioner takeaway is that authorisation must evaluate request context at runtime, not just the standing permission set.

Requester-to-action accountability is becoming a first-class identity issue. When a downstream system only sees the agent's service account, attribution depends on stitching logs across Slack, Anthropic, and the connected enterprise system. That is a governance problem, not merely a logging problem. The field should treat correlation integrity as part of agent identity design, because auditability collapses when request, execution, and evidence live in separate systems.

Shared agents will accelerate the identity blast radius of collaboration platforms. A Slack-native agent with enterprise permissions turns a chat channel into an execution surface. That broadens the blast radius of a single access decision far beyond the original user. The implication is that collaboration platforms now need identity controls that behave more like privileged execution environments than messaging tools, especially where agents can reach code, data, and business systems.

Clarity on autonomy matters more than branding. The article describes a persistent, context-aware shared agent, but the core analytical point is not whether the product is labeled autonomous. What matters is that runtime behaviour can change faster than human review cycles can track. The practitioner conclusion is to classify these systems by decision authority and execution scope, then govern them as non-human identities with agent-specific controls.

From our research library:

• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Read next: AI Agent Authorisation Guide

What this signals

Shared agent governance needs a different operating model: once multiple people can drive one permissioned agent, access review alone stops being enough. The control problem shifts to deciding whether each action is acceptable at the moment of invocation, which is why runtime authorisation belongs beside identity governance, not after it.

Identity blast radius expands inside collaboration tools: a Slack-native agent can turn ordinary conversation into an execution surface across code, data, and business systems. In that environment, the agent's service account becomes the real security boundary, and teams should treat each connected integration as part of the agent's privilege domain.

AI access is still being granted too broadly: 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey. That pattern makes shared-agent governance urgent because broad privilege turns routine prompts into high-impact actions.

For practitioners

• Define the shared agent as the governed principal Map each shared AI agent to a named owner, a permission boundary, and a revocation path so the agent can be reviewed independently of any single requester.
• Insert policy checks before each tool call Require runtime authorisation before GitHub, Jira, CRM, data warehouse, or MCP actions execute, because post-event review cannot prevent the unsafe call itself.
• Separate requester logs from execution logs Correlate the Slack requester, the agent identity, and the downstream system action in one workflow so investigators can reconstruct intent and impact without manual log stitching.
• Limit the agent's connected-system scope Scope each shared agent to the minimum set of systems and actions needed for its business function, then reassess when the conversation context expands into sensitive workflows.
• Treat ambient monitoring as a privileged behaviour Review any proactive conversation monitoring or follow-up capability as an always-on access pattern, with separate approval and detection requirements from user-initiated actions.

Key takeaways

• Shared AI agents move the decisive control point from the user to the agent's runtime permissions and tool calls.
• The governance challenge is not only identity assignment but also intent control, traceability, and action-level authorisation.
• Teams that rely on visibility after execution will miss the real risk, because the unsafe decision has already happened before downstream systems record it.

Key terms

• Local AI Agent: A local AI agent is software that runs on a personal device or server and can interact with files, applications, and system tools directly. Unlike a browser-based assistant, it may hold local memory, use messaging channels, and execute commands, which makes operating system security and access control part of its threat model.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Requester-to-Action Correlation: Requester-to-action correlation is the ability to link the person who initiated a task to the identity that executed it and the systems it touched. It is essential when logs split across chat, agent, and enterprise systems, because accountability depends on reconstructing the full path.
• Agent intent: The immediate goal implied by an AI agent’s current sequence of tool calls. Unlike static automation, intent can change at runtime, which is why identity governance for agents has to look beyond permission sets and toward execution-time behaviour.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.