Claude Tag shifts enterprise AI from identity to control risk

At a glance

What this is: Claude Tag is a shared enterprise AI agent with its own identity and permissions, and Zenity's core finding is that the security boundary moves from the user to the agent.

Why it matters: That matters because IAM, PAM, and NHI teams now have to govern agent intent, not just authenticate users or issue credentials.

👉 Read Zenity's analysis of Claude Tag and shared AI agent control risk

Context

Claude Tag changes the basic access model for enterprise AI agents. Instead of acting only on behalf of a named user, the agent carries its own credentials and permissions across shared workspaces, which means the control boundary is no longer tied to the employee who asked the question.

That shift matters for identity governance because downstream systems, logs, and policy checks now need to reason about the agent as the actor. If teams only track where the agent is deployed and what it can connect to, they still miss the runtime decision that determines whether a tool call should execute.

The article frames the real problem as control risk, not just identity sprawl. Once a shared agent can act for multiple people, the programme has to decide how intent is authorised, how it is logged, and which identity model governs the action path.

Key questions

Q: How should security teams govern shared AI agents that act for multiple users?

A: Treat the shared agent as the governed identity, not the person who typed the request. Give it separate entitlements, log its actions independently, and require policy decisions before each tool invocation. That is the only way to keep delegated action from becoming unchecked shared privilege.

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: What breaks when AI agent logs and system logs do not align?

A: Investigations lose the link between human intent and machine execution. Anthropic's task log may show who asked, but connected systems only show the shared agent account. Without correlation, security teams cannot prove whether an action was valid delegation, prompt manipulation, or accidental overreach.

Q: Who is accountable when a shared AI agent takes the wrong action?

A: Accountability sits with the organisation that granted the agent its permissions and control model, then with the teams that operate it day to day. The human requester may have initiated the conversation, but the security failure usually comes from the policy boundary that allowed the agent to execute without sufficient inline control.

Technical breakdown

Shared agent identity and delegated permissions

Claude Tag assigns permissions directly to the agent rather than inheriting them from the human requester. That means the agent can access systems such as GitHub, Jira, Google Drive, or Salesforce through its own service account, while multiple users in a Slack channel can trigger actions through the same identity. This is different from a personal copilot model, where access remains bounded by the individual user's entitlements. The technical consequence is that authorization must be evaluated at the agent layer, not only at the human layer, because the action is executed by the shared identity that owns the integration.

Practical implication: map every shared agent to a distinct service identity and review its grants separately from the users who invoke it.

Runtime control before tool invocation

The article's central technical claim is that visibility is insufficient when an AI agent can call tools, APIs, or an MCP server. Each interaction is a runtime decision that should be evaluated before execution, because once the request reaches the destination system, the authorization outcome is already locked in. That makes pre-execution policy enforcement the key control point. In practical terms, the architecture must inspect the request context, the prompt content, the target system, and the intended action before allowing the call to proceed.

Practical implication: enforce inline policy checks ahead of every API, MCP, or tool call instead of relying on downstream detection.

Intent correlation across separate logs

Claude Tag creates a logging split that many programmes are not ready for. Anthropic's own log can tie a task back to the requester, but connected systems and SIEM tools only see the shared agent identity. That means intent and execution are split across two records that must be stitched together to reconstruct who asked for what and what the agent actually did. Without that correlation layer, security teams cannot reliably distinguish legitimate delegated action from manipulative or malicious prompting inside the channel.

Practical implication: build correlation between requester context and agent execution logs before allowing the agent into sensitive workflows.

NHI Mgmt Group analysis

Claude Tag is not creating a new identity class so much as exposing an old governance blind spot. The article shows a shared agent with its own permissions acting on behalf of multiple users, which breaks the assumption that access can be evaluated only at the human edge. The implication is that identity governance now has to treat the agent as the control point, not the requester.

Intent, not identity, becomes the primary governance variable once a shared agent can act for many users. The article makes clear that downstream systems only observe the agent account, while the human requester is preserved elsewhere. That means policy, logging, and accountability are no longer aligned by default. Practitioners need to rethink whether their programme is governing who can authenticate, or what an agent is allowed to decide and execute.

Visibility without runtime enforcement is a monitoring layer, not a control. Zenity's analysis correctly separates deployment discovery from action prevention. Knowing which channels use the agent and which systems it can reach does not stop a prompt injection, a malicious instruction, or an unintended pull request. Runtime authorization is the real control surface because it is the last point where the action can still be denied.

Shared-agent identity should be treated as an NHI governance problem with agentic consequences. The permissions, credentials, and service accounts look like classic machine identity issues, but the decision-making layer is different because a human can trigger the same agent from different contexts. That is where NHI practice meets agentic risk. The practitioner conclusion is that governance models must cover both the identity object and the decision path it enables.

Agent intent is a named control risk: authorization must now be judged at execution time. Traditional access review assumes stable permissions and clear human ownership, but a shared AI agent turns both assumptions into moving parts. That is the control gap this article surfaces. The programme response is not just more inventory, but a redefinition of what is being authorised in the first place.

From our research:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most teams cannot reliably inventory the identities behind shared agent access.
• For a deeper lifecycle view, read Ultimate Guide to NHIs , Static vs Dynamic Secrets for the control shift from long-lived credentials to ephemeral access patterns.

What this signals

Shared-agent governance will force IAM teams to collapse identity, logging, and policy into one operating model. A Slack-embedded agent that can act for multiple people is no longer a niche integration problem. It is a programme design problem that cuts across NHI, PAM, and AI governance. Teams that cannot join requester context to execution context will struggle to answer basic accountability questions when incidents occur.

The practical next step is to define which agent actions are admissible before they are executed, not after they are detected. That means building policy logic around tool invocation, request context, and destination sensitivity, then testing those controls against the real collaboration systems where work happens.

Identity blast radius: shared agents expand the number of people who can exercise one service identity, so the governance boundary becomes the agent's permissions rather than the user's role. Teams should expect this to surface in access reviews, logging design, and incident response workflows as more collaboration platforms add persistent agent features.

For practitioners

• Separate shared agents from human accounts in access reviews Inventory each shared AI agent as its own identity object, then review its permissions, connected systems, and approval paths independently from the people who trigger it in Slack.
• Enforce pre-execution policy checks for every tool call Require inline evaluation before the agent can reach GitHub, Jira, Google Drive, Salesforce, or an MCP server, so the deny decision happens before the request leaves the control plane.
• Correlate requester context with agent actions Join the human requester record with the agent's service-account log so security teams can reconstruct intent, action, and outcome from a single investigation trail.
• Limit ambient monitoring to low-risk workflows first Treat proactive conversation monitoring and follow-up as higher-risk behaviour than simple on-demand responses, and restrict those features until the policy model can explain every downstream side effect.

Key takeaways

• Claude Tag shifts the control problem from individual user access to shared agent decision-making, which changes how identity boundaries should be drawn.
• The main operational risk is not just broader permissions, but the split between requester intent and what downstream systems can actually see.
• Teams need runtime authorization, separate agent inventories, and log correlation if they want to govern shared AI agents without losing accountability.

Key terms

• Shared AI agent: An AI agent used by more than one person, where the agent carries its own permissions and can act across a shared workflow. The important distinction is that the governed identity is the agent itself, not the individual requester, so accountability and access control must be designed around the agent's runtime behaviour.
• Runtime control: A control that evaluates an AI or machine action before it executes, rather than after the fact. In practice, it checks the request context, destination, and policy fit at the moment a tool call is about to happen, which is essential when downstream systems will only see the agent account.
• Intent correlation: The process of linking the human request that triggered an action to the machine record that shows what executed. It matters when a shared agent logs its own activity separately from the requester, because investigations depend on joining those records to reconstruct accountability and detect misuse.

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.

This post draws on content published by Zenity: Claude Tag Didn’t Create Another Identity Problem. It Created a Control Risk. Read the original.