Claude Tag security risks expose the agent identity gap

At a glance

What this is: This is an analysis of seven Claude Tag security risks and the key finding that agent identity solves attribution but leaves runtime authorization, visibility, and accountability gaps unresolved.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to govern who can invoke an agent, what it may reach, and who can see the output, not just whether the agent is authenticated.

By the numbers:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).

👉 Read Akto's analysis of Claude Tag security risks and agent identity gaps

Context

Claude Tag is an agent identity pattern for shared collaboration spaces, where the AI agent acts under its own principal instead of borrowing a person's credentials. In identity terms, that changes the control point from user login to the moment the agent acts, which is exactly where many enterprise programmes are weakest.

The governance problem is not whether the agent can authenticate. It is whether the requesting person, the agent scope, the destination data, and the audience are all authorised at runtime. That is a classic NHI design issue, but with agentic AI the blast radius can expand through natural-language invocation, shared-channel visibility, and delayed accountability.

Key questions

Q: How should security teams govern AI agents that inherit authority from other identities?

A: Security teams should govern AI agents by tracking identity lineage, not just credentials. That means recording the originating identity, the delegated authority path, and the runtime context for each action. If an agent can inherit permissions from humans, services, or other agents, policy has to evaluate the full chain before access is granted or continued.

Q: Why do AI agents complicate least privilege in IAM programmes?

A: AI agents complicate least privilege because their useful scope is often broader than a traditional service account, but their actual authority should still be narrower at each action. The control has to move from static entitlement management to request-time decisioning, especially for tool use and downstream side effects.

Q: What breaks when shared channels are allowed to invoke privileged agent identities?

A: Channel membership starts functioning like an access grant, even when the channel was created for collaboration rather than privilege. That creates an identity blast radius, because adding or retaining a member can expand who can trigger sensitive actions. The failure is governance drift, not authentication failure.

Q: Who is accountable when an agent performs an action that the requester could not do directly?

A: Accountability sits with both the requester and the organisation that allowed the delegation path. The agent may be the recorded actor in logs, but that does not erase the requester’s authority problem. Teams need logging that ties the human request, the agent principal, and the touched data together.

Technical breakdown

Agent identity versus requester identity

Claude Tag gives the agent a durable principal in connected systems, which means systems log the agent rather than the human who typed the request. That improves attribution for the actor, but it does not automatically bind the requester’s authority to the resulting action. The technical risk is a split between authentication, which proves the agent exists, and authorisation, which must decide whether the requester may cause the agent to act. Without that binding, a natural-language request can become an unauthorised indirect access path.

Practical implication: enforce per-action authorisation against the requester, not only the agent principal.

Shared-channel responses and audience leakage

A shared collaboration channel creates a visibility layer that is separate from the original data source. The agent may retrieve information correctly, yet the response can still be overexposed because every channel participant can see it. This is not a failure of authentication or retrieval. It is a post-access disclosure problem, where the wrong audience receives a valid answer. In identity programmes, this is where data sensitivity, collaboration membership, and response routing collide.

Practical implication: scope responses to the requester or check audience access before posting into shared channels.

Runtime policy enforcement at the tool call

The decisive control point is the runtime call to a tool, repository, or external system. At that moment, policy can evaluate the requester, the agent’s scope, the target resource, and the sensitivity of the operation together. Pre-provisioning alone is too blunt because it assumes the agent’s behaviour will stay inside a static envelope. Agentic systems can chain requests, switch context, and reuse channel-based authority in ways that static permission models do not anticipate.

Practical implication: move sensitive decisions into runtime policy checks rather than relying on baseline entitlements alone.

Threat narrative

Attacker objective: The attacker aims to use the agent as a privileged intermediary to access systems, disclosures, or actions that would otherwise be blocked.

1. Entry occurs when a user invokes the agent in a shared channel and the request reaches systems that the user could not access directly.
2. Escalation occurs when the agent’s own permissions satisfy the request even though the requester lacks equivalent authority, creating an indirect access path.
3. Impact occurs when the action, response, or retrieved data reaches a broader audience than the original data source would have allowed.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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

NHI Mgmt Group analysis

Agent identity solves attribution, not authorisation: The most important Claude Tag lesson is that giving an AI agent its own principal does not answer whether the requesting person is entitled to cause the action. That gap moves identity governance from login-time trust to runtime decisioning, which is where most IAM stacks still rely on static entitlements. Practitioners should treat this as a control boundary shift, not an authentication improvement.

Runtime authorisation is the real control plane for agentic AI: The article shows that the decisive decision is made when the agent calls a tool or reads data, not when it joins the workspace. That is where the requester, the agent scope, the data sensitivity, and policy must be evaluated together. Existing access review cadences are too slow for this pattern, so governance has to move into the execution path.

Shared collaboration spaces create an identity blast radius: When channel membership becomes the trigger for invoking agent authority, collaboration governance quietly becomes access governance. That is a structural problem because channel membership was built for teamwork, not for privileged delegation. The implication is that identity teams must reclassify shared channels as access-bearing control surfaces, not just communication spaces.

Ephemeral prompts create audit debt: If the instruction that triggered an action lives only in a transient message or document comment, the organisation may know what the agent did without being able to prove why it did it. That breaks incident reconstruction and weakens accountability chains. The operational conclusion is that conversational control paths need the same evidentiary treatment as privileged sessions.

Policy overlays only matter if they exist at enforcement time: A future identity-aware overlay for dual-check authorisation is useful only when it is present in the runtime path, not as roadmap language. Until then, the agent’s own scope is the effective control surface. Practitioners should read that as a warning that delegated AI access will keep expanding faster than governance unless enforcement is anchored in the call itself.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 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, according to AI Agents: The New Attack Surface report.
• For a broader control model, compare that with OWASP Top 10 for Agentic Applications 2026, which frames identity and privilege abuse as a core agentic risk pattern.

What this signals

Runtime governance will become the differentiator for agentic AI programmes. With 80% of organisations already reporting AI agents acting outside intended scope, per the AI Agents: The New Attack Surface report, the practical issue is no longer whether agents can be authenticated. The issue is whether your policy stack can decide in-session, with enough context, before a tool call or response leaks beyond intended authority.

Agent identity will keep collapsing into access governance. Once a channel-scoped agent can be invoked by anyone in the space, collaboration controls become privilege controls by another name. That means identity teams need to inventory invocation paths, not just principals, and they should anchor their model to NIST Cybersecurity Framework 2.0 and the OWASP Top 10 for Agentic Applications 2026 where runtime authorisation and tool misuse are explicit concerns.

For practitioners

• Bind requester authority to every agent action Require the system to evaluate the human requester’s permissions alongside the agent’s scope before any sensitive repository, CRM, warehouse, or deployment action is executed.
• Treat collaboration membership as access governance Map which users can invoke each channel-scoped agent identity and review membership changes as access changes, especially where a channel can reach production data or administrative tools.
• Route sensitive responses to the correct audience Prevent shared-channel overexposure by scoping replies to the requester or by checking the audience’s access rights before the agent posts the result.
• Log the triggering context as evidence Capture the message, comment, or document instruction that caused the action so investigators can reconstruct intent when the agent later appears in logs as the sole actor.
• Enforce least privilege at runtime, not just provisioning Start with read-only access, then expand only when the agent’s actual task history justifies it, and make the runtime policy decide whether each call should proceed.

Key takeaways

• Claude Tag-style agent identity improves attribution, but it does not by itself solve who may cause an action or who may see the result.
• The evidence from agent security research shows that scope creep and unintended actions are already common, which makes runtime authorisation a present-tense control problem.
• Identity teams should treat shared channels, requester binding, and per-action policy checks as part of the same governance stack, not separate operational concerns.

Key terms

• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Authorization Laundering: Authorization laundering occurs when a person causes an action they could not perform directly by routing the request through a more privileged intermediary. In agentic systems, the agent can become that intermediary, so the control problem shifts from login authentication to delegated authority and runtime checks.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• 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.

What's in the full article

Akto's full blog post covers the operational detail this post intentionally leaves for the source:

• Per-risk examples showing how Claude Tag permissions can be misused in shared channels and direct messages
• Runtime enforcement patterns for dual-check authorisation and response scoping across connected systems
• A practical agent identity governance checklist for inventory, ownership, and access review
• Tooling context for runtime protection, shadow AI discovery, and red teaming of agent actions

👉 Akto's full post covers the Claude Tag risk scenarios, runtime controls, and governance checklist in more operational detail.

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 identity security capability across human, machine, and autonomous systems, it is worth exploring.