Threat explainer
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.
Protect the coding tools your team already uses without forcing everyone to become a security expert.
Real protection moments, scrubbed for safety before becoming public learning pages.
A redacted example of a local secret read attempt.
Why it was risky
Env files often hold API keys or service credentials.
What Guard did
HOL Guard paused the read before file contents left the machine.
A redacted example of an MCP tool with a misleading description.
Why it was risky
The tool description asked the agent to read credentials and pass them as arguments.
What Guard did
HOL Guard paused the tool call and flagged the description for review.
A redacted example of a prompt injection via a file comment.
Why it was risky
The instruction was embedded in an HTML comment invisible to the developer.
What Guard did
HOL Guard paused the command and showed the source of the instruction.
A redacted example of a supply-chain attack via npm install.
Why it was risky
Postinstall scripts run with full permissions before anyone reviews the code.
What Guard did
HOL Guard paused the install and showed the script contents.
Practice attack patterns with static simulations. Nothing dangerous executes.
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 here are limited to the current HOL Guard support contract and do not imply universal model or harness protection.
Partially, and only at supported local action boundaries. HOL Guard is local-first runtime control on the developer machine for shell, secrets/file reads, MCP server change, and plugin/skill install. It can require approval before supported shell actions. It does not cover commands executed outside the supported harness path, and it does not guarantee semantic safety of every command a human explicitly approves.
No. HOL Guard complements rather than replaces EDR, endpoint antivirus, OS sandboxes, or a complete command-control program. Coverage is harness- and event-specific. Unsupported or partial surfaces are not claimed as protected.
No. A scan is not a safety guarantee and cannot intercept runtime shell actions. The current public catalog scanner is registry-broker-fallback static scoring, not a live exploit test. Catalog plugin counts are not Registry Broker agent counts. Runtime benchmark fixtures are modeled, not live attack measurements.
Threat dossier · P1
A coding agent can move from natural-language context to terminal execution without a separate human translating the instruction.
Direct answer
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.
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.
Policy pattern
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.
Step 1
Stop execution and preserve the redacted requested action.
Step 2
Assess filesystem/repository/network state for changes.
Step 3
Restore from known-good state where required.
Step 4
Update policy for the root risky action class.
Neighboring threat classes that share attack paths or trust boundaries with this dossier.