Claude Enterprise exposes a new identity attack surface for IAM

At a glance

What this is: This analysis argues that Claude Enterprise turns developer identity into an expanded agentic attack surface by inheriting local permissions, connector credentials, and standing access.

Why it matters: It matters because IAM, PAM, and lifecycle controls must now govern the human, the workload, and the AI-assisted execution path together, or over-broad access becomes immediately reusable by the agent.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read P0 Security's analysis of Claude Enterprise identity risk

Context

Claude Enterprise is not just another collaboration tool. The identity issue is that an agent running in the developer's OS context inherits the developer's permissions, so any standing privilege already present becomes available to the agent as well.

That changes the governance problem for IAM teams. Access to code, documentation, secrets, and production systems can no longer be treated as a human-only entitlement if the same permissions are being exercised by an AI agent and by connector processes such as MCP servers.

For organisations using AI in delivery workflows, the typical starting position is already risky: access was broad before the agent was added, and the agent simply makes that breadth operationally visible in new ways.

Key questions

Q: How should security teams govern AI agents that inherit developer permissions?

A: Treat the host account as the real control plane. If the developer identity has broad repository, cloud, or secret access, the agent will inherit that reach. Teams should collapse standing privilege first, then introduce task-scoped access, approval checkpoints, and connector review so the agent cannot reuse human permissions beyond the intended work.

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

A: Because least privilege is usually defined at provisioning time for a stable human or service account. An agent can select actions dynamically inside the same session, so the reachable privilege set depends on runtime behaviour, connector scope, and the surrounding content it reads. That makes static entitlement thinking incomplete.

Q: What do security teams get wrong about MCP server access?

A: They often treat connectors as lightweight integrations instead of identity-bearing trust paths. A static token or poorly scoped OAuth grant can expose code, logs, or production data through the agent even when the core platform looks well controlled. Every connector needs ownership, authentication review, and revocation discipline.

Q: Who is accountable when an AI agent exfiltrates sensitive data?

A: Accountability sits with the organisation that allowed the agent to inherit broad access and with the team that approved the connector and oversight model. If the workflow can move secrets or production data without durable auditability, the governance failure is in access design, not only in model behaviour.

Technical breakdown

OS-level identity inheritance in agentic workflows

Claude Code operates inside the local user context, so it does not create a new identity boundary by default. The agent inherits the permissions, tokens, filesystem reach, and application access already held by the developer account. That means least privilege is defined by the human workstation posture, not by the AI interface itself. If the developer can read a secret, access a repo, or touch a production environment, the agent can usually do the same. Practical implication: treat the host identity as the security boundary and remove broad local rights before agent deployment.

Practical implication: reduce the developer account's baseline privilege before enabling agentic workflows.

MCP servers, static credentials, and connector sprawl

Model Context Protocol servers and other connectors extend an agent's reach into internal systems, but they often rely on static API keys or persistent tokens. Those credentials are effectively standing privileges because they remain valid until explicitly revoked, and many are deployed outside normal identity governance workflows. In practice, the agent is only as controlled as the connector fleet behind it. A single unaudited integration can become a high-trust path into source code, logs, or sensitive data stores. Practical implication: inventory every connector and enforce authentication standards for each one.

Practical implication: register and review every connector as an identity-bearing integration.

Prompt injection as an identity abuse path

Prompt injection does not attack the IAM stack directly. Instead, it manipulates the agent's reasoning so the agent uses its authorised access in an unintended way, such as exfiltrating secrets or forwarding sensitive content. This is why agentic security cannot stop at authentication or SSO. The model may be fully authenticated and still be socially engineered into abusing valid permissions. Human confirmation checkpoints help, but if they are disabled or bypassed, the control disappears. Practical implication: treat untrusted content as a potential command channel whenever the agent can act on it.

Practical implication: keep human confirmation on for any action that can reveal or move sensitive data.

Threat narrative

Attacker objective: The attacker wants to turn an authorised AI workflow into a data-exfiltration and access-abuse path without needing to break primary authentication.

1. Entry occurs when the agent is run inside a developer account that already has broad access to repositories, production systems, or secrets.
2. Escalation happens through inherited permissions and connector credentials, especially when MCP servers expose static tokens or OAuth scopes beyond the task at hand.
3. Impact follows when prompt injection or malicious content redirects the agent to exfiltrate secrets, access unauthorised systems, or leak sensitive data into logs.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

Claude Enterprise does not create a separate trust domain when it inherits developer identity. The agent operates inside the same OS-level context as the user, so the security model is still anchored to the developer's standing privileges. That means the governance question is not whether the AI is clever enough to be safe, but whether the underlying human account was ever appropriate for machine reuse. Practitioners should treat the developer workstation as a privileged execution environment, not a neutral workspace.

Standing access is the identity failure mode this article exposes. Broad repo, secret, and production permissions were designed for human-paced work where access is periodically reviewed and manually constrained. That assumption fails when an AI agent can exercise those permissions continuously, copy them into connector workflows, and act faster than review cycles can react. The implication is that access review alone cannot compensate for an access model that was never meant to be mirrored by an agent.

Connector sprawl creates ephemeral-looking systems with persistent privilege debt. MCP servers and similar integrations may feel temporary to development teams, but static keys and long-lived tokens turn them into durable trust paths. This is a classic non-human identity problem wrapped inside an AI workflow, and it belongs in the same governance stack as service accounts and privileged automation. Practitioners should classify every connector as an identity-bearing control point, not a convenience layer.

Prompt injection shows that authorisation and intent are no longer aligned. The agent may be authorised to act, but the content that triggers action is not necessarily trustworthy. That breaks the old assumption that valid access plus human oversight equals safe execution. IAM and PAM programmes now have to assume that authorised execution can still be adversarially redirected, which changes how teams define acceptable use, review checkpoints, and logging depth.

Identity blast radius: once a developer account, connector token, and agent runtime are linked, a single over-broad entitlement becomes reusable across code, data, and production paths. This is the most important governance concept in the article because it explains why isolated permissions stop mattering once they are chained through agentic workflows. Practitioners should measure the reachable blast radius of each identity path, not just the number of permissions attached to it.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
• For the AI agent angle, AI Agents: The New Attack Surface report shows that 80% of organisations report agent actions beyond intended scope, which is why governance must extend beyond the human account.

What this signals

Standing privilege is becoming the default failure mode for agentic workflows. Once a developer account is allowed to power an AI assistant, the organisation inherits whatever that account can already reach. With 88.5% of organisations saying their non-human IAM practices lag human IAM, according to The 2024 Non-Human Identity Security Report, the gap is structural, not cosmetic.

Identity blast radius is the right concept for this problem. Teams should stop asking only whether an agent is authenticated and start asking what it can reach through host identity, connectors, and delegated scopes. That lens aligns naturally with the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs, because the reachable blast radius changes as people move roles, projects, and privileges.

As AI workflows spread across development and operations, the programme risk is no longer isolated prompt misuse. It is the combination of broad human access, persistent connector credentials, and weak lifecycle governance, which is why IAM, PAM, and workload identity teams need one operating model instead of three disconnected ones.

For practitioners

• Rebase developer access before enabling agents Remove standing admin rights, narrow repo and cloud permissions, and make agent execution depend on the least-privileged human account available. Review local OS access, not just SaaS entitlements.
• Register every MCP server and connector Document the authentication method, token type, data scope, and owner for each integration. Block any connector that uses a static API key without an explicit lifecycle review and revocation path.
• Keep human confirmation on sensitive actions Require approval for secret access, production changes, and data movement that an agent can trigger from untrusted content. Do not allow auto-approve mode on workflows that can reveal credentials or alter systems.
• Tie AI access to lifecycle events Revoke or downgrade agent-linked permissions when developers move roles, change projects, or leave the organisation. Treat AI access as part of the same joiner, mover, leaver process as human and workload identity.

Key takeaways

• Claude Enterprise becomes an IAM problem when it inherits a developer's standing permissions inside the same OS context.
• The article's core warning is that static connector credentials and prompt injection can turn authorised agent actions into a broad identity blast radius.
• Reducing developer privilege, governing every connector, and tying AI access to lifecycle events are the controls that change the outcome.

Key terms

• Agentic workflow: A workflow where an AI system can choose actions and use tools within a task rather than only generating text. In identity terms, the risk is not the model itself but the permissions it inherits, the connectors it can call, and the oversight that limits or fails to limit execution.
• Standing privilege: Persistent access that remains available until someone explicitly removes it. In AI-assisted environments, standing privilege matters because an agent can reuse the same reach immediately and repeatedly, turning broad human entitlements into machine-amplified exposure across code, data, and production systems.
• Model Context Protocol server: A connector that gives an AI system access to external tools, services, or data sources. Security depends on the authentication method, token lifespan, and scope of data exposed, because an unaudited server can become a durable non-human identity path with hidden trust.
• Identity blast radius: The total set of systems, data, and actions reachable through one identity path. For agentic AI, this includes the host account, delegated tokens, connector scopes, and approval settings, which means the practical risk is how far one entitlement can propagate when exercised by software.

What's in the full article

P0 Security's full analysis covers the operational detail this post intentionally leaves for the source:

• How Claude Code behaves across local user context, confirmed operations, and auto-approve settings
• Specific examples of MCP server authentication patterns and where static API keys create standing privilege
• Practical guidance for reviewing role explosion, managed settings, and auditability in AI-enabled workspaces
• Lifecycle handling for joiners, movers, and leavers when AI access is tied to developer accounts

👉 P0 Security's full post covers the connector, prompt injection, and access review details behind the risk.

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.