AI agents inherit developer identity, expanding the access surface

At a glance

What this is: This is a blog analysis of AI coding agents inheriting developer identity, with the core finding that the agent’s access expands to whatever the developer can already reach.

Why it matters: It matters because IAM, PAM, and NHI programmes cannot govern agent activity if they still treat the agent as just another tool instead of an actor using human privileges.

Context

AI coding agents change the access model when they run inside a developer terminal rather than a constrained service boundary. In this setup, the agent can use the same credentials, sessions, and repository access that the developer already has, which makes the identity question more important than the model question.

Token Security’s argument is that the control gap is not prompt quality but identity separation. Once an agent can read local secrets, invoke authenticated CLIs, and access internal systems through MCP integrations, traditional blast-radius assumptions built for static machine identities no longer describe the risk accurately.

Key questions

Q: What breaks when AI coding agents inherit a developer’s identity?

A: The main failure is that the agent is no longer operating as a separate principal. It can reach whatever the developer can reach, which collapses segmentation, attribution, and least-privilege assumptions. Security teams lose the ability to treat the model as a bounded tool, because its practical access is defined by the human session it inhabits.

Q: Why does an agent inside a trusted developer session increase risk even without a prompt attack?

A: Because the core risk is not only model manipulation. If the session already contains authenticated access, the agent can exercise real privilege through normal commands and integrations. That means the attacker’s job becomes finding a path into the session, not bypassing access control at each target system.

Q: What are the signs that an AI agent architecture is becoming too hard to debug or govern?

A: Warning signs include opaque routing decisions, limited replay capability, and difficulty tracing how inputs became actions and outputs. If teams cannot unfurl loops, inspect parameter extraction, or reconstruct a complete interaction path, they are likely losing operational control. At that point, observability gaps become a production risk, not just an engineering inconvenience.

Q: Should organisations treat autonomous agents like human users or service accounts?

A: Organisations should not treat autonomous agents as simple human analogues. They behave like governed non-human identities with added runtime decision-making, so they need identity boundaries, action checkpoints, and clear accountability. Human-style certification cycles alone are too slow for systems that can complete sensitive work within one session.

Technical breakdown

Why inherited developer identity changes the access boundary

When an AI coding agent runs inside a developer’s trusted environment, it can inherit whatever that user can access: cloud roles, Kubernetes clusters, SaaS applications, local secrets, and active CLI sessions. That is different from a service account model, where access is intentionally scoped and lifecycle-managed. The practical issue is that the agent is not operating as a separate principal by default, so the access boundary becomes the developer’s entire working context. In identity terms, the agent is acting through delegated human privilege, not through a cleanly isolated non-human identity.

Practical implication: model the agent as a distinct identity surface and stop assuming the developer account boundary is sufficient protection.

Why prompt injection is not the primary control problem

Prompt injection matters, but it is not the whole risk story when the agent already has legitimate credentials. If the agent can run authenticated commands, query databases, or touch cloud resources inside a trusted session, then the main exposure is not model manipulation alone. The control issue is privilege inheritance combined with execution authority. That shifts the problem from text safety to access governance, because an attacker does not need to trick the model into creating access if the session already contains it. The attack surface is therefore the credentialed runtime, not just the language interface.

Practical implication: treat prompt security as one layer, but govern the credentials and tools the agent can actually use.

How MCP and pre-authenticated tooling widen the inherited privilege graph

MCP integrations and pre-authenticated CLIs extend the inherited identity problem across systems. Once the agent can call aws, gcloud, kubectl, or third-party tools from a developer session, every connected system inherits the same trust assumptions. That creates a privilege graph that is broader than any single application, because tool access, session state, and stored tokens all become part of one execution path. For NHI governance, this resembles overprivileged machine access, but with a human origin and machine-speed use pattern that is harder to attribute cleanly.

Practical implication: inventory tool chains and session-backed credentials together, not as separate controls.

Threat narrative

Attacker objective: The attacker objective is to exploit the agent’s inherited developer privileges to reach internal systems, secrets, and production resources through a trusted session.

1. Entry occurs when an AI coding agent runs inside a developer terminal with the user’s existing permissions, local secrets, and authenticated sessions.
2. Credential access follows through stored SSH keys, cached API tokens, and pre-authenticated CLIs that the agent can invoke without re-authentication.
3. Escalation happens when the agent chains those credentials into cloud, Kubernetes, database, and SaaS actions across MCP-connected systems.
4. Impact is broadening of the access surface to the developer’s full environment, with weaker attribution and a larger blast radius than the team likely intended.

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 our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Inherited developer identity is not a convenience layer, it is an identity control failure. The article shows an AI coding agent operating inside the developer’s terminal with the same practical reach as the human who launched it. That collapses the assumption that non-human activity can be governed through a separate service account boundary. The practitioner conclusion is that identity inheritance must be treated as a first-class design decision, not an implementation detail.

Least privilege was designed for principals whose scope can be defined before execution begins. That assumption fails when an AI agent can decide which commands to call, which systems to query, and which integrations to chain during the session. The implication is not just more access review. It is that provisioning-time privilege models do not fully describe runtime agent behaviour, which is a structural problem for NHI governance.

Access attribution becomes unreliable when a human identity and an agent share the same runtime context. The article’s central concern is not simply that the agent can do more, but that security teams cannot easily prove which actor used which credential, on which system, and on whose behalf. That weakens incident reconstruction, policy enforcement, and accountability across IAM, PAM, and endpoint telemetry. Practitioners need to treat attribution as an access control requirement, not a logging afterthought.

Identity blast radius is now the more useful concept than model capability. The model may be the visible component, but the harm comes from the environment it inherits. Once the agent can reach cloud roles, SSH keys, local secrets, and MCP-connected tools, the blast radius is defined by the developer’s operational footprint. Practitioners should re-evaluate trust boundaries around sessions, not around prompts.

AI agents are becoming a new non-human identity class that sits between human delegation and machine execution. They are not static service accounts, but they also are not autonomous systems in the strict sense described by identity governance models. That middle position is where many teams will misclassify the risk. The practitioner takeaway is to govern agents as identities with their own lifecycle, even when they borrow human credentials temporarily.

From our research library:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Inherited privilege is the real control plane problem: once an AI coding agent can operate with a developer’s cloud roles, SSH keys, and cached API tokens, the programme must govern the session boundary rather than the model boundary. That changes how teams design least privilege, because the effective principal is the combined human-plus-agent runtime, not the application alone.

Attribution must move into access governance: if a security team cannot tell whether a command came from a person or an agent, then audit trails are no longer enough to support review or incident response. The programme needs policy on which sessions can be agent-enabled, what tools they can call, and how those actions are separated from human activity.

For practitioners

• Define agent identity boundaries Map every place an AI coding agent can inherit a developer session, cached token, SSH key, or cloud role, then decide which of those inheritances are acceptable.
• Separate human and agent attribution Require logging that links commands, tool calls, and data access to the specific session actor so investigators can distinguish human action from agent action.
• Scope MCP and CLI access as a unit Review MCP integrations, pre-authenticated CLIs, and local credential stores together because they form one effective privilege chain once an agent can invoke them.
• Treat inherited access as temporary privilege Where agents must operate in a user session, confine that access to narrowly defined tasks and remove any persistent privilege that does not need to survive the session.

Key takeaways

• AI coding agents become risky when they inherit developer privileges inside trusted sessions, because their practical reach extends far beyond the model itself.
• The governance challenge is not only credential exposure but also attribution, since human and agent actions can become indistinguishable in normal telemetry.
• Teams that still treat these systems as tools instead of identities will miss the control point that actually limits blast radius and incident ambiguity.

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.
• 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.
• Attribution gap: The attribution gap is the distance between what an AI agent did and what the enterprise can prove about who authorized it, what it was allowed to do, and who is accountable. It is an identity and governance problem that becomes visible during audits, incidents, and legal disputes.
• Session-Backed Privilege: Privilege that exists only because a live authenticated session already contains the necessary credentials or trust. For AI coding agents, session-backed privilege is especially risky because the agent can reuse it without a fresh identity decision at each step.

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 building or maturing an IAM programme, it is worth exploring.