Command Execution

Command execution vulnerabilities occur when a skill can run arbitrary operating system commands on the host machine. This is the most direct path from compromised skill to compromised computer. A skill that invokes shell-level functions (exec, eval, popen, system calls) or uses process-spawning libraries with attacker-influenced input gives the attacker a shell.

In the AI agent context, the attacker-influenced input is often the agent itself. The agent interprets a prompt-injected instruction, then passes it to a skill with command execution capabilities. The skill dutifully runs whatever the agent tells it to.

Aguara detects both direct patterns (skills that invoke shells or process-spawning APIs) and indirect ones (skills that build command strings from template variables, use eval-like constructs, or chain together in ways that produce command execution as an emergent behavior). The INDIRECT_010 rule specifically catches cases where command execution arises from the interaction between multiple skills rather than a single one.

Most AI agent frameworks run on the user local machine or in a cloud environment with broad permissions. The agent typically has the same file system access, network access, and credential access as the user who launched it. When a skill executes a command, that command runs with all of those permissions.

This is fundamentally different from a web application vulnerability. A command injection in a web app is limited by the web server user permissions, network segmentation, container isolation. An AI agent running on a developer laptop can read SSH keys, access cloud credentials, modify source code. There is usually zero isolation between the agent and the developer full environment.

The compounding risk with MCP is that users connect agents to multiple servers simultaneously. A skill from a trusted MCP server might be perfectly safe on its own, but when combined with a malicious skill from another server that injects commands through the agent, the trusted skill becomes the execution vector.

If your skill needs to execute commands, use allowlists rather than blocklists. Define exactly which commands are permitted, with exactly which arguments, and reject everything else. Never construct commands by concatenating strings. Use parameterized execution (pass arguments as arrays, not shell strings) and validate every input against a strict schema.

Sandboxing matters. If your skill runs code, run it in a container, a VM, or at minimum a restricted user account with no network access and a read-only filesystem. The overhead is worth it. A skill that can only write to /tmp and cannot reach the network is dramatically safer than one that inherits the user full permissions.

As a user, be deeply skeptical of any skill that requests shell access or code execution capabilities. Check whether it invokes shell-level functions or process-spawning APIs. If it does, verify that inputs are validated and execution is sandboxed. If you cannot verify these things, do not install the skill.