The Identity Surface You're Not Watching: Three Layers of Coding Agent Risk

There's a widespread assumption in enterprise security that identity is a problem IAM programs know how to solve. Provision the right access, enforce least privilege, audit the credential chain, and you've addressed the identity risk. For human users and traditional service accounts, that's approximately correct. For coding agents, it misses two-thirds of the problem.

Coding agents don't have a single identity. They operate across a layered identity surface, and each layer carries its own risk profile. The layer IAM programs are designed to manage is the outermost one. The deeper two are where the attacks that IAM can't detect actually live.

Zenity Labs' research into the coding agent threat model maps this identity surface in detail. What follows is the practical implication for security teams trying to assess their actual exposure.

Layer 1: Static Credentials (What IAM Sees)

The first identity layer is the one IAM programs were designed for: the credentials present at the time the agent launches. The developer's SSH keys, API tokens in environment variables, credentials stored in .env files, OAuth tokens in the browser, and service account keys the developer has access to.

The agent inherits all of them. In the average enterprise developer environment, that's access to source repositories, CI/CD pipelines, cloud infrastructure, and multiple SaaS integrations. IAM can inventory this access, enforce least privilege where it's applied, and audit the credential chain. That's valuable.

What IAM can't tell you is that the agent, rather than the developer, is the one deciding how to use those credentials. That distinction doesn't show up in any IAM log. The identity is legitimate. The authorization is valid. The problem is that the agent making the decision to use those credentials may be operating under instructions the developer never gave.

Layer 2: Session Tokens and Dynamic Permissions (What IAM Misses)

When a coding agent executes a task, it typically mints or inherits tokens at runtime. These tokens may grant different scopes depending on which systems the agent is accessing and which tools it's invoking. Session-level permissions are dynamic, context-dependent, and often broader than the specific task requires, because scoping them precisely to each task is not yet standard practice in most enterprise deployments.

These session tokens are not the same as the static credentials in the developer's environment. They're created at execution time, they may have different expiration windows, and they often grant access that the developer's static credential set technically allows but that no human ever explicitly provisioned for the agent's current task.

IAM programs don't see this layer. The tokens are minted by legitimate systems as part of normal operation. They don't appear in the identity inventory. They don't have named owners. And when a coding agent session is compromised, they're the mechanism by which an attacker's injected instructions access systems that weren't the intended target of the session.

Layer 3: MCP-Inherited Permissions (What No One Is Watching)

The third layer is the one with the least visibility and the highest complexity. When a coding agent connects to a Model Context Protocol (MCP) server, it inherits that server's permissions for the duration of the tool call. If the MCP server has broad access, the agent's effective permission set expands accordingly, often in ways that were never explicitly authorized and that no IAM review would surface.

Zenity Labs research has documented how MCP servers expand agent integration paths in ways that create novel attack vectors. A developer installs an MCP server for a legitimate purpose, a GitHub integration, a database connector, a documentation tool. The server executes with the permissions of the connected agent. Those permissions are inherited for every tool call the agent makes through that server. And if the MCP server is itself compromised, or if it was malicious by design when installed from a public marketplace, every agent that connects to it becomes an attack vector.

Third-party MCP servers installed from public marketplaces are treated as trusted by default. They execute outside the sandbox. They have access to everything the agent has access to. And in most enterprise environments, no one is auditing their runtime behavior.

Why the Layered Surface Matters for Defense

The practical implication of this layered identity surface is that IAM-only approaches to coding agent security address only the outermost layer of a three-layer problem. You can implement least privilege for static credentials, and you should. But that intervention doesn't address session tokens minted at runtime, permissions inherited through tool calls, or the behaviors that agents take under those dynamically acquired permissions.

Treating MCP server installation with the same security review process applied to third-party software is a meaningful step forward. Assessing the source, the permissions the server requests, and the behaviors it declares before allowing it into a developer's agent configuration closes part of the gap at the posture layer. Runtime monitoring that tracks what MCP servers actually return, and what the agent does immediately afterward, closes the gap at the detection layer.

The inventory challenge is foundational. You can't apply identity governance to layers you can't see. Active scanning across developer endpoints, repository configurations, and MCP server registries surfaces the full picture, including shadow deployments and MCP server connections that were never formally reviewed. That inventory is the prerequisite for every downstream control.

IAM was built to answer whether an identity had access. For coding agents, the harder question is what three layers of identity they're actually operating under, whether the permissions they've accumulated were ever intentionally granted, and whether the actions they're taking under those permissions are consistent with what any human actually authorized. Most organizations can't answer those questions yet, and the attacks are designed for exactly that gap.

The complete identity threat model and governance framework are in the eBook → Download The Ultimate Guide to Securing Coding Agents