AI agents inherit developer identity, expanding the access surface

At a glance

What this is: This analysis argues that Claude Code behaves as an identity problem because it inherits developer permissions and expands the effective access surface across cloud, code, secrets, and MCP-connected systems.

Why it matters: IAM, PAM, and NHI teams need to treat agentic tools as actors with inherited privilege, because visibility and attribution break down when human and machine actions share the same session context.

By the numbers:

• Almost 80% of the Fortune 100 have already deployed enterprise AI.
• According to McKinsey, 23 percent of respondents are scaling agentic AI in their enterprise with an additional 39 percent now experimenting with AI agents.
• Research consistently shows high success rates, often 85% or more, against state-of-the-art defensive prompting techniques.

👉 Read Token Security's analysis of Claude Code and the AI agent identity problem

Context

AI agents become an identity problem when they inherit the permissions, tools, and sessions of the user who launches them. In this case, Claude Code is not a constrained helper running in isolation; it operates in developer terminals with access to cloud roles, local secrets, and internal systems, which pushes the governance question from model behaviour to inherited privilege.

That matters because existing IAM models assume a clean line between the human operator and the non-human actor. Once a tool can act inside the same authenticated context as the developer, the control problem shifts to attribution, scope, and separation of duties across human identity, workload access, and non-human identity governance.

Key questions

Q: How should security teams govern AI agents that inherit human credentials?

A: They should treat the agent as an actor operating inside the human’s trust boundary and scope the environment accordingly. That means limiting inherited access, separating production permissions from interactive sessions, and requiring traceable attribution across cloud, endpoint, and platform logs before deployment. The goal is to prevent human privilege from becoming default agent privilege.

Q: Why do AI coding agents create new IAM risk even when prompt injection is addressed?

A: Because prompt injection only affects what the model may be persuaded to do, while the deeper risk is what the agent can already do with inherited credentials. If the agent has cloud roles, cached tokens, or SSH access, it can cause damage without needing a successful prompt attack. Identity scope, not prompt quality, is the main boundary.

Q: How can teams tell whether an AI agent is operating inside safe access boundaries?

A: They should test whether every credential, tool, and system the agent can reach is explicitly enumerated and justified for the task. If the answer depends on whatever the developer already had open, the boundary is not safe. A workable boundary produces a complete audit trail and a narrow set of approved actions.

Q: What is the difference between monitoring an AI agent and governing its identity?

A: Monitoring tells you what the agent did after the fact. Governing identity determines what it was allowed to do in the first place and whether those permissions were separable from the human operator. Both are necessary, but only identity governance can stop inherited access from becoming uncontrolled access.

Technical breakdown

Inherited developer identity and privilege amplification

Claude Code inherits the identity of the developer who launched it, which means the agent does not need its own separate service account to become powerful. It can operate with the same cloud IAM roles, cached tokens, SSH keys, and local CLI sessions already available to that user. That creates privilege amplification: the tool’s effective reach is the union of everything the person can already access. From an identity governance perspective, this collapses the boundary between human and machine execution and makes session context part of the control surface.

Practical implication: map every agent to the exact human session and privilege set it inherits before allowing production use.

MCP integrations and cross-system tool reach

The article highlights MCP integrations as a key expansion point because they let an agent connect to internal and third-party systems through approved tool links. MCP does not create identity on its own, but it increases the number of places where a privileged session can be used. In practice, the risk is not only data exposure. It is delegated action across systems that were never designed to share a single identity context. That makes tool routing, credential reuse, and logging coherence central governance problems.

Practical implication: inventory every MCP-connected tool and treat it as part of the agent’s effective access graph.

Attribution gaps between platform logs and enterprise controls

The article’s strongest technical point is that no single control plane can explain what happened end to end. Platform logs show what the agent did inside Claude Code, endpoint telemetry shows process activity, and cloud logs show role-based API calls. But none of those views alone answer who used which credential, from which device, on whose behalf. That is an identity correlation problem, not just a monitoring gap. When session identity is shared, attribution becomes ambiguous and auditability degrades.

Practical implication: require cross-system identity correlation before approving agentic workflows in regulated or high-risk environments.

NHI Mgmt Group analysis

AI agents inherit the developer’s trust boundary, which means the real control plane is no longer the model. Claude Code’s risk profile is shaped by the permissions already attached to the launching user, not by a separate agent account. That is why cloud roles, local secrets, and pre-authenticated tools matter more than model output quality. The practitioner conclusion is straightforward: governance must follow the inherited identity, not the branding of the AI tool.

Least privilege was designed for a stable actor with a stable access profile. That assumption weakens when an agent can invoke cloud CLIs, read local secrets, and traverse MCP links within a single work session. The implication is not merely to tighten permissions, but to recognise that the classic provisioning-time view of privilege does not fully describe agent behaviour. Practitioners need to rethink how access is bounded when execution happens inside a human-authenticated shell.

Claude Code exposes an identity attribution problem that most observability stacks are not built to solve. Platform telemetry, endpoint telemetry, and cloud audit logs each tell part of the story, but none of them alone can prove which actor used which access path. That makes shared-session agent use a governance issue, not just a logging issue. The practitioner conclusion is to treat cross-domain attribution as a prerequisite for deployment, not a post-incident investigation task.

Prompt injection is a distraction when the deeper issue is delegated authority. The article correctly notes that even solved prompt injection would not remove the core exposure if the agent can already act with production permissions. That shifts the field away from model-only security and toward identity-aware execution control. The practitioner conclusion is to focus on who can act, with what permissions, and under what traceable boundary.

Agentic AI is becoming a new identity class, but only if teams stop treating it as an application layer concern. Once agents coordinate tasks, chain tools, and invoke other agents, the inherited access graph becomes more complex than traditional workload identity. NHI governance already has the vocabulary for this problem, but it must be applied to agentic runtime behaviour rather than static secrets alone. The practitioner conclusion is to extend identity governance to every AI actor that can execute without fresh human approval.

From our research:

• 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, according to AI Agents: The New Attack Surface report.
• Only 44% of organisations have implemented any policies to govern AI agents, even though 92% agree governing them is critical to enterprise security.
• For a broader NHI baseline, read Ultimate Guide to NHIs for lifecycle, visibility, rotation, and offboarding patterns that help separate human and machine access.

What this signals

AI agent inheritance debt: once an agent borrows a human session, the programme inherits the human’s blast radius unless it can prove separation at the identity layer. The practical signal to watch is whether your access review process can still tell which actions were human and which were machine after the fact. Teams that cannot answer that question should assume their current operating model is already too coarse for agentic use.

With 33% of organisations reporting AI agents have accessed inappropriate or sensitive data beyond intended scope, the governance problem is already showing up in production behaviour. That makes this a controls-and-visibility issue, not a future policy exercise. Security teams should prepare for agent sessions to become a distinct audit class, not just another form of application activity.

The next phase of AI governance will be defined by whether organisations can model inherited privilege as a bounded identity state rather than as an application feature. That is where the overlap with zero trust, workload identity, and non-human identity governance becomes operational. For practitioners, the signal is simple: if you cannot segregate agent access from the human launch context, you do not yet have an agent governance model.

For practitioners

• Separate agent execution from human production identities Do not let an AI coding assistant run inside a developer context that already contains broad cloud, database, or repository access. Use narrowly scoped identities, session isolation, and explicit approval boundaries so the agent cannot inherit full human privilege by default.
• Map the inherited access graph before rollout List every credential, CLI session, repository, cloud role, and MCP connection the agent can reach from the launch environment. Treat that inventory as the real attack surface, not the model’s advertised feature list.
• Correlate identity across platform, endpoint, and cloud logs Require a joinable audit trail that links the human initiator, the agent session, the device, and the downstream API calls. Without that correlation, attribution fails and incident response cannot distinguish human action from agent action.
• Limit MCP tool exposure to task-specific scopes Approve only the connectors and commands needed for the immediate workflow, and review them as part of the agent’s effective permission set. If the agent can chain tools across systems, the control problem has already expanded beyond a single application boundary.

Key takeaways

• AI agents become an identity problem when they inherit the permissions of the human who launches them, turning session context into the real control boundary.
• The article shows that platform telemetry, endpoint logs, and cloud audit trails are individually insufficient for agent attribution, which leaves a governance gap even when controls exist.
• Practitioners should isolate agent access, restrict connected tools, and require cross-system identity correlation before allowing production use.

Key terms

• Inherited identity: An inherited identity is a session or access context that a non-human actor receives from a human or upstream system rather than being assigned its own standalone account. In agentic environments, this can include cloud roles, cached tokens, SSH keys, and live CLI sessions that the agent can reuse.
• Access surface: Access surface is the full set of systems, data, tools, and credentials an identity can reach. For AI agents, it is broader than the model itself because it includes everything available in the launching user’s environment and any connected integrations the agent can invoke.
• Attribution gap: An attribution gap exists when logs show activity, but not clearly which actor caused it or on whose behalf it occurred. In shared human-agent sessions, this weakens auditability, complicates incident response, and makes policy enforcement difficult across platform, endpoint, and cloud systems.
• Agentic workflow: An agentic workflow is a task sequence where an AI system can choose actions, call tools, and continue execution across multiple steps. When this happens inside a trusted identity context, governance must address both what the workflow can do and which identity state it is borrowing.

What's in the full article

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

• How Claude Code interacts with developer terminals, local secrets, and pre-authenticated CLI sessions in practice
• The specific visibility controls the vendor describes for platform-level oversight, including compliance and analytics APIs
• The article’s examples of multi-step, cross-application agent workflows and why they complicate attribution
• The source’s explanation of how enterprises are applying agent governance in live deployments

👉 The full Token Security post covers the access-surface details, platform controls, and attribution challenges in more depth.

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.