Agentic IDE trust assumptions collapse under shell built-ins

At a glance

What this is: This research shows that trusted shell built-ins in an agentic IDE can be abused to poison environment variables and convert approved commands into code execution.

Why it matters: It matters because IAM, PAM, and NHI programmes increasingly have to govern delegated execution contexts where the trust boundary is the command environment, not just the command itself.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

👉 Read Pillar Security's research on trusted shell commands becoming agent attack vectors

Context

Agentic IDE security is not just about blocking bad commands. The problem is that shell built-ins and environment variables create a hidden execution layer, so a command that looks safe can still change how later tools behave. In this case, Cursor's command allowlist treated the visible command as the control point, while the real risk sat in the poisoned context around it.

For identity teams, the issue sits squarely in non-human identity governance. The environment becomes a delegated privilege surface, and approvals that were designed for human-paced execution do not reliably constrain agent-driven workflows. That is why tools, scripts, and shells that appear routine can become part of an attack chain when the identity executing them is software, not a person.

Key questions

Q: What breaks when agentic IDEs rely on command allowlists for safety?

A: Command allowlists break when the dangerous behaviour sits in the environment, not in the visible command. A trusted shell built-in can modify inherited state and prepare a later approved command to execute attacker-controlled code. The control checks syntax, but the exploit lives in runtime context.

Q: Why do shell built-ins create a governance problem for AI agents?

A: Shell built-ins create a governance problem because they mutate process state without looking like ordinary external commands. In agentic workflows, that makes them privileged operations that can reshape later execution, which means the identity boundary includes environment state as well as command permissions.

Q: How can security teams reduce environment poisoning risk in agent workflows?

A: Security teams should isolate agent execution state, monitor inherited variables, and treat runtime context as part of the approval decision. The key is to prevent one step from silently preparing the next step. If the environment is reset or sandboxed between actions, the attack chain loses its hidden staging area.

Q: What is the difference between approving a command and approving its runtime context?

A: Approving a command means the syntax is acceptable. Approving runtime context means the surrounding variables, shell state, and inherited execution conditions are also safe. In agentic systems, those are separate decisions, because a benign command can still become malicious when the environment has been poisoned beforehand.

Technical breakdown

Shell built-ins as an execution primitive

Shell built-ins such as export, typeset, declare, readonly, and unset do not behave like ordinary external binaries. They are executed by the shell itself, which means they can modify process state, environment variables, and later command behaviour without looking like a traditional command launch. In agentic IDEs, that matters because the security model often evaluates the visible command string, not the state it creates. When built-ins can alter PATH, PAGER, PYTHONWARNINGS, BROWSER, or PERL5OPT, the attack surface shifts from command approval to environment poisoning. The result is that a benign-looking operation can become the launch point for arbitrary code execution when a later trusted tool is invoked.

Practical implication: treat shell built-ins as privileged operations and monitor environment mutation separately from command execution.

Why allowlists fail when context is the payload

Allowlists are designed to distinguish approved commands from unapproved ones, but they do not understand how one approved command can silently reshape the meaning of the next. In this research, an empty allowlist did not stop the attack because the dangerous action was not the command being approved, but the environment the command prepared. That is a classic context problem. A visible command such as git branch or python3 script.py can remain harmless in isolation while still executing attacker-controlled behaviour because the shell or interpreter reads poisoned variables at runtime. In other words, the policy gate inspected syntax, but the exploit lived in runtime state.

Practical implication: add controls for inherited environment state, not only for the command strings that users approve.

Sandbox bypass through trusted developer tools

The attack chain works because developer tools such as Git and Python depend on ambient shell state for normal behaviour. If PAGER is redirected, output display becomes an execution trigger. If Python warning handlers and interpreter lookup variables are chained, code can be executed through modules that were never meant to carry attacker instructions. This is not a memory corruption flaw. It is a trust boundary flaw in which the agent is given enough authority to prepare the runtime, and the runtime then executes with the user's or system's privileges. The security failure is architectural: the agent is trusted to stage the environment for future actions, but that staging is itself an attack surface.

Practical implication: isolate execution environments so that tools cannot inherit attacker-modified process state across agent steps.

Threat narrative

Attacker objective: The attacker wants to turn trusted developer workflows into remote code execution and persistence paths without requiring a suspicious command prompt.

1. Entry occurs when malicious content convinces the agent to run shell built-ins that are implicitly trusted, even when the allowlist is empty.
2. Credential access or abuse happens when environment variables are poisoned so later trusted tools execute attacker-controlled behaviour instead of their normal function.
3. Impact follows when the approved command triggers sandbox bypass and remote code execution, letting the attacker persist code or run arbitrary processes under the victim's privileges.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Agentic IDE trust models fail because they validate commands, not execution context. Cursor's allowlist logic focused on what the user could see, but the exploit lived in the shell state that built-ins silently changed. That means the control model was aimed at syntax while the attack used environment inheritance as the payload path. The implication is that agent security cannot be judged by command approval alone; runtime context is part of the identity surface.

Shell built-ins are a governance problem, not a convenience feature. export, typeset, declare, and similar built-ins are often treated as low-risk because they are common shell primitives. In agentic workflows, they become privileged state-mutating operations because they alter how later commands execute. This is a non-human identity issue as much as a developer tooling issue, because the identity executing the sequence can chain state changes without human review. Practitioners should treat built-ins as part of delegated authority, not as neutral plumbing.

Runtime isolation is the boundary that matters when agents can stage their own environment. The attack shows that a safe command can become dangerous only after the agent has prepared the environment around it. That collapses the assumption that command approval equals execution safety. The phrase context poisoning window captures the failure mode: a short, silent period in which environment state is modified before the visible trigger is run. Practitioners need to recognise that the window exists because the identity is software-driven, not human-paced.

Least privilege loses precision when privilege includes mutable process state. Traditional least-privilege models assume the sensitive decision is access to files, systems, or APIs. Here, the sensitive decision is access to the shell's inherited state, which can reshape later tool behaviour without changing the approved command. That means the true privilege boundary is broader than many IAM or PAM programmes model today. The implication is that teams must rethink what counts as an entitlement when an agent can rewrite its own execution conditions.

The agent security paradox is that trusted commands become attack vectors only under autonomous execution. The same command set that feels harmless in a human workflow becomes dangerous when the agent can combine, sequence, and time those commands without an approval gate between steps. That is why the problem scales beyond Cursor: any agentic toolchain that trusts inherited context inherits the same failure mode. Practitioners should assume that command trust and runtime trust are separate controls, not one control expressed twice.

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.
• Another 80% of organisations report their AI agents have already acted beyond intended scope, including unauthorised systems access, sensitive data sharing, and credential exposure.
• That pattern makes the 52 NHI breaches Report a useful next lens for understanding how delegated identity failures become real incidents.

What this signals

Context poisoning window: teams need to start modelling the interval between a trusted environment mutation and the next visible command as a distinct control gap. Once agent workflows can rewrite their own runtime state, traditional approval checkpoints no longer describe the real point of risk. That shifts attention toward isolation, session reset, and variable-level monitoring, not just command filtering.

The broader signal is that agentic IDEs expose a new form of delegated privilege creep. The same workflow can be safe under human pacing and unsafe under software pacing, which means governance has to distinguish between what a user intended and what the agent actually staged. For teams building controls, that is the point where NHI management, PAM, and developer tooling converge.

Practitioners should also watch for the same pattern in other agent stacks, especially where shell, interpreter, or browser state persists across steps. The security question is no longer whether a command is allowlisted, but whether the agent can precondition the next command into a different security outcome. That is a governance design issue, not just a detection issue.

For practitioners

• Audit shell built-ins as privileged operations Inventory where agentic IDEs, shells, or automation layers allow export, typeset, declare, readonly, and unset to run without separate review. Classify these as environment-mutating actions and route them through stronger control paths than ordinary command approval.
• Separate command approval from environment approval Require explicit controls for inherited variables such as PATH, PAGER, PYTHONWARNINGS, BROWSER, and PERL5OPT before any trusted tool runs. Approval of the visible command should not imply approval of the runtime state it depends on.
• Isolate agent execution state between steps Reset or sandbox process state between agent actions so one approved operation cannot prepare the next one. This matters for shells, developer tools, and interpreter chains that read ambient environment values at runtime.
• Review trusted developer tools as execution sinks Map tools that consume shell context, including Git, Python, Perl, and pagers, then document which environment variables can alter their behaviour. Use that mapping to decide where to block agent-driven execution or require a higher approval tier.

Key takeaways

• Agentic IDEs can turn trusted shell built-ins into control bypasses because the exploit lives in environment state, not just in visible commands.
• The research shows that allowlists and sanitizers can miss the real attack surface when an approved command inherits poisoned runtime context.
• Practitioners should separate command approval from environment approval and treat runtime isolation as the core defence for agent workflows.

Key terms

• Agentic IDE: An agentic IDE is a development environment in which an AI system can execute actions, call tools, and chain steps with limited human intervention. The security challenge is not just code generation. It is the ability to stage execution context and influence later commands or tools.
• Shell Built-In: A shell built-in is a command implemented by the shell itself rather than by an external program. Because it can alter environment state, variables, and execution flow, it behaves like a privileged control surface in agentic workflows and should be governed accordingly.
• Environment Poisoning: Environment poisoning is the abuse of inherited variables or shell state to alter how later commands, interpreters, or tools behave. In agent-driven systems, it turns runtime context into an attack vector and can convert an approved action into code execution.
• Context Poisoning Window: A context poisoning window is the silent interval between an attacker modifying runtime state and a later visible command or tool using that state. The period matters because the approval step may look safe while the execution outcome has already been preconditioned.

Deepen your knowledge

Agentic IDE trust boundaries and non-human execution risk are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for developer agents or shell-driven automation, it is a practical place to start.

This post draws on content published by Pillar Security: The Agent Security Paradox, focusing on trusted commands in Cursor becoming attack vectors. Read the original.