Identity Inheritance

Identity Inheritance is the pattern where an MCP server or AI agent component automatically receives the identity, credentials, and authority of its parent process or installer at runtime, typically without the operator explicitly granting that authority. The phenomenon is built into the default execution model of STDIO transport and most other connector spawning patterns: when a parent spawns a child, the child runs as the same UID, with the same environment variables, accessing the same filesystem and credential stores.

For AI agents this default produces a security mismatch with operator intent. Operators who install an MCP server typically think they are granting the server access to a specific tool surface (read these files, call this API, query this database). They are actually granting the server everything the parent process can do — git operations against private repos, cloud-API actions through inherited tokens, signing operations through inherited key material, network access through inherited credentials. The gap between intended scope and inherited scope is where OWASP ASI03 (Identity and Privilege Abuse) findings live.

Why Identity Inheritance Is the Default

Identity inheritance is the operating-system default because it makes process spawning fast and convenient. Most software engineering does not need an additional identity layer; classical applications and their helper processes share trust by design. The default works for most cases.

It does not work for AI agents because the agent processes adversarial input as part of normal operation. Every document the agent reads, every tool output it receives, every webpage it fetches is potential influence over what the agent decides to do. With full inherited identity, any successful prompt injection hijacking the agent has the host's full authority. The threat model is asymmetric — the host process is supposed to be the security boundary, but the host process is exactly what the agent's reasoning step controls.

Defensive Patterns

Defending against identity-inheritance abuse requires explicit constraint at spawn time. Run MCP server processes with dedicated UIDs distinct from the developer's. Use environment-variable allowlists that strip credential-bearing variables (AWS_*, GH_TOKEN, OPENAI_API_KEY, signing-related variables) from the child's environment. Apply filesystem isolation (containers, mount namespaces) so the child cannot reach credential stores in the developer's home directory. Apply network isolation so the child cannot reach systems outside its declared tool surface.

Each of these is a deviation from the OS default and requires explicit operator action. The MCP Security Checklist covers each constraint with operational guidance. For deeper context, see the OWASP ASI03 explainer.