Unsafe command execution
How prompt injection and malicious tools cause AI agents to run dangerous shell commands.
AI tools can run shell commands. Sometimes they run the wrong ones.
Unsafe command execution happens when an agent runs rm -rf, curl to external endpoints, git push to unknown remotes, or installs packages based on injected instructions rather than user intent.
HOL Guard turns these moments into private receipts first, then public lessons only after redaction and moderation.
Harness setup guides
Protect the coding tools your team already uses without forcing everyone to become a security expert.
Redacted warnings
Real protection moments, scrubbed for safety before becoming public learning pages.
codex
Codex was stopped before reading an env file
A redacted example of a local secret read attempt.
Open guideclaude-code
Claude Code was stopped before calling an untrusted MCP tool
A redacted example of an MCP tool with a misleading description.
Open guidecursor
Cursor was stopped before following a hidden instruction
A redacted example of a prompt injection via a file comment.
Open guideopencode
OpenCode was stopped before running a malicious postinstall script
A redacted example of a supply-chain attack via npm install.
Open guideSafe labs
Practice attack patterns with static simulations. Nothing dangerous executes.
Threat dossier · P1
Unsafe shell and destructive commands dossier
A coding agent can move from natural-language context to terminal execution without a separate human translating the instruction.
Direct answer
What is unsafe shell and destructive commands?
Unsafe command execution is the point where an agent turns a mistaken, poisoned, or overbroad plan into a shell action with destructive or irreversible consequences.
Coverage statements below are limited to the current HOL Guard support contract and do not imply universal model or harness protection.
Representative attack path
Defensive model only. This sequence omits weaponized payloads and is not attributed to a specific incident unless a source explicitly says so.
Step 1
Context or planning produces a risky command.
Step 2
Agent requests shell execution.
Step 3
Command reaches files, repositories, networks, or credentials.
Step 4
Irreversible state change or data exposure occurs.
Coverage boundary
What this control can cover
- Supported pre-command policy and approval boundaries.
- Explicit policy for destructive or high-risk command classes.
What it does not prove or prevent
- Commands executed outside the supported harness path.
- Semantic safety of every command a human explicitly approves.
Policy pattern
Policy pattern for unsafe shell and destructive commands
Keep untrusted context or overbroad autonomy from becoming unconditional execution authority on supported action surfaces.
Use when: A coding agent can move from natural-language context to terminal execution without a separate human translating the instruction.
Decision pattern
- Identify the trust boundary and consequential action class.
- Apply least privilege and the narrowest supported policy.
- Require review for sensitive or ambiguous actions.
- Preserve only redacted, versioned evidence needed to reproduce the decision.
Limitations
- Commands executed outside the supported harness path.
- Semantic safety of every command a human explicitly approves.
If you suspect prompt injection
Step 1
Response 1
Stop execution and preserve the redacted requested action.
Step 2
Response 2
Assess filesystem/repository/network state for changes.
Step 3
Response 3
Restore from known-good state where required.
Step 4
Response 4
Update policy for the root risky action class.