Stop Dangerous AI Agent Commands Before They Run

Do not ask an AI coding agent whether its own command is safe. Put a policy decision between the request and the shell, then evaluate the resolved executable, arguments, working directory, identity, and destination.

A denylist of scary strings will fail. Commands can be aliased, encoded, wrapped in scripts, split across steps, or made dangerous by a single path or flag.

*Normalize the request before policy evaluation; log the final decision after execution.*

Define dangerous in terms of impact

Start with resources and outcomes. A dangerous command may delete or overwrite protected data, read a secret, change an access policy, modify a security control, install untrusted code, contact an unapproved host, or escape the workspace.

The same executable can be safe or dangerous. git status in a disposable repository is low impact. A force push to a protected branch is not. curl can retrieve a public schema or exfiltrate a credential.

Use the AI agent threat model to name these outcomes before writing rules.

Prefer narrow actions over a general shell

If the agent needs to run tests, expose a test action with a fixed executable and bounded options. If it needs package information, expose a read-only package query. Every narrow tool removes combinations the policy engine would otherwise have to understand.

When a shell is unavoidable, run it under a dedicated identity in a disposable workspace. Limit writable roots, executable paths, environment variables, network egress, process lifetime, and resource consumption.

Anthropic's Claude Code security guidance discusses permissions and prompt-injection risk in that product. OWASP's LLM application risks provide broader categories. Your command policy still has to reflect the host and repository you operate.

Normalize before matching policy

Resolve the command to the executable that will run. Expand relative paths, symlinks, environment variables, aliases, and working-directory changes. Decode URLs and inspect the final host after redirects. Parse compound commands rather than scanning a raw string for keywords.

Do not allow a safe prefix to hide an unsafe suffix. Redirection, command substitution, pipes, subshells, and script interpreters can change the effect without changing the first token.

The controls in secure Claude Code tools apply the same idea to tool definitions and configured components: trust the resolved capability, not the display name.

Use an allow, approve, block model

Allow routine operations whose executable, arguments, target, and context match policy. Block actions with no legitimate place in the workflow. Send exceptional but valid operations to approval.

An approval request should show the command after normalization, affected files or service, identity, network destination, and expected effect. The reviewer should not have to reconstruct a shell pipeline from a truncated preview.

Approval must be bound to the exact request. If the arguments change, the decision expires.

Put hard boundaries below the policy engine

Policy is not the only layer. Use operating-system permissions, containers, read-only mounts, network controls, branch protection, package-lock enforcement, and scoped cloud roles. A bypassed hook should encounter a second boundary.

Protect the guard itself. Agents should not be able to edit policy files, disable hooks, clear audit logs, or replace the executable that enforces decisions.

Test commands without causing damage

Build a fixture workspace containing synthetic secrets, decoy protected paths, and a local test server. Avoid live credentials and production hosts.

Your regression set should include:

• a routine read and test command that must pass;
• a write outside the allowed root;
• a path traversal and symlink escape;
• an outbound request to an unapproved destination;
• a command that changes a policy or hook;
• a multi-step chain whose second action is prohibited.

Record expected and actual decisions. Rerun the set when the agent host, model, tool schema, or policy changes. Prompt injection prevention should feed cases into the same regression loop, because injected instructions often become dangerous only when they reach a tool.

Where AgentGuard fits

AgentGuard publicly describes risk decisions around shell commands, file access, network requests, secrets, and sensitive writes, plus supported component scans. Its documented Claude Code integration includes pre/post tool hooks; other clients may use different integration depths.

Use it where the integration can observe the intended command path. It does not remove the need for a sandbox, least privilege, branch protection, or application-side authorization.

Run a harmless command-control test with a permitted action and a policy violation before widening an agent's permissions.