How the attack works
An AI agent with tool-calling ability is directed (by a user, a compromised prompt, or a chained instruction) to run a command or script. The call includes a parameter known to be dangerous: shell=True (which allows arbitrary shell injection), a forced/destructive flag, a flag that disables SSL certificate verification, a command that sets the SUID bit on a file, or a wildcard delete against the filesystem. The tool executes with that parameter, and whatever safety boundary it was supposed to enforce is bypassed. This is a single-step detection: it catches the dangerous call itself, not necessarily how the agent was steered into making it or what happened afterward.
Why it matters
A dangerous parameter used this way can let an attacker run arbitrary shell commands, delete files broadly, intercept traffic that should have been encrypted, or plant a privilege-escalation backdoor via SUID — any of which can lead to data loss, system compromise, or persistent unauthorized access.
What you can do
- Restrict which tools and parameters an agent is allowed to invoke; deny shell=True, wildcard deletes, and SSL-bypass flags by default.
- Require human approval or a secondary check before an agent runs any command with destructive or security-bypassing flags.
- Review agent tool-call logs for these specific patterns and confirm each instance was intentional and authorized.
- Exclude known benign cases explicitly, such as documented admin scripts or Dockerfile cache cleanup, rather than disabling the check broadly.
Known benign look-alikes
- Authorized system administration scripts with confirmed destructive intent
- Dockerfile cleanup steps using rm -rf on package cache directories