What should teams do immediately when an agent can modify shell state before approval?

Why this is treated as an integrity incident, not a normal approval flow

When an agent can alter shell state before approval, the approval boundary has already been crossed in a meaningful way. The risk is not just that a command runs, but that the next command may inherit modified context, including variables, aliases, functions, PATH entries, or startup file changes. That is why the session should be treated as compromised until the shell environment is reset and inspected.

For agentic workflows, the approval moment must be evaluated against the state the command will actually inherit, not just the text being approved. A pristine prompt with poisoned context is still unsafe because the execution environment can quietly redirect behaviour after the user or policy engine says yes.

That is the same control idea described in AI Agent Authorisation Guide: approval has to be tied to per-action authority, not assumed session safety.

What shell state can be poisoned before the next command executes

Teams should think in terms of inherited execution context. The most dangerous changes are the ones that survive into the approved command without being obvious in the prompt, such as shell functions that shadow binaries, exported variables that change tool behaviour, altered command search paths, sourced startup files, and hidden aliases that rewrite intent. In practice, the approval gate is only useful if it accounts for these hidden inputs.

Resetting the environment is therefore not ceremonial housekeeping. It removes the attacker-controlled context that could cause an approved command to run something different from what was reviewed. Inspection should focus on what the shell will source or inherit, not just on recent command history.

For agent-driven terminal use, the practical boundary is the same one highlighted in AI Coding Agents Security Guide: the terminal is not safe if secrets, startup state, or execution paths can be influenced before a human or policy decision.

Immediate containment steps for the approval window

The fastest safe response is to stop using the current shell context, preserve enough evidence to understand what changed, and re-enter from a clean environment. That means the affected session should be considered untrusted until the shell state, startup files, exported variables, aliases, functions, and any agent-written configuration are reviewed and either reverted or discarded. If the agent touched profiles or environment files, those changes deserve priority because they can affect every later command.

• Stop the approval flow in the current session.
• Open a fresh shell or reset to a known-clean environment.
• Inspect shell state, startup files, and environment variables for agent-written changes.
• Review command history and any temp files or wrappers the agent created.
• Only resume once the next approved command will execute in a verified context.

That operational pattern aligns with the broader guidance in AI Agent Observability, Audit and Incident Response Guide, which treats abnormal agent action as something to attribute, contain, and investigate before continuing.

Risk and Threat Considerations

The main threat is context poisoning, where the agent modifies the shell in a way that changes the meaning of a later approved command. That can lead to command hijacking, secret exposure, unintended outbound connections, or execution of attacker-chosen code under an otherwise legitimate approval path.

Failure mechanism: The shell inherits altered variables, functions, aliases, or startup content, so the reviewed command executes in a contaminated environment rather than the one the approver expected.

Impact: A single approval can complete an attack chain, because the malicious context may redirect the command, exfiltrate credentials, or persist across follow-on commands.

Practitioner Guidance

What to prioritise: Prioritise environment reset before forensic curiosity. If the shell can still inherit attacker-controlled state, any later approval is operating on a false premise.

What to verify: Verify the exact execution context that the next command will use, including startup files, exported variables, aliases, functions, PATH precedence, and any wrappers or helper scripts the agent introduced.

Common mistake: Treating a clean prompt as proof of a clean session is the mistake to avoid. The visible command may be harmless while the inherited state is not.

Practitioner takeaway: Approval is only meaningful when the execution environment is trustworthy, so the safe default after pre-approval shell modification is to contain first, inspect second, and resume only from a clean context.

Related resources from NHI Mgmt Group

• How should teams think about AI agent privileges?
• How should security teams handle AI agent visibility?
• How should security teams monitor AI agent activity without disrupting developers?
• What is the difference between human identity governance and AI agent governance?