A Copilot agent is given an MCP tool that executes arbitrary shell commands on a build server to run tests. The tool runs with the same user account that owns the build server's CI/CD credentials. A security engineer proposes sandboxing. Which sandboxing approach provides the strongest security boundary for this tool's execution environment?
Select an answer to reveal the explanation.
Short Explanation
You need a real sandbox, not just filtering. Run the tool in an ephemeral container with no network access, read-only filesystem mounts, and a dedicated low-privilege user that can't touch CI/CD credentials. That contains the blast radius even if the agent gets tricked.
Full Explanation
When an MCP tool executes shell commands, it is the highest-risk tool type in any agent's toolkit. The sandbox must address three threat vectors: Lateral movement via credentials: If the tool runs with the same account that holds CI/CD credentials, a malicious command can exfiltrate those credentials to an external server. The fix is a dedicated low-privilege user that has no access to production credentials. Persistence: If the tool runs on a long-lived server with a persistent filesystem, a compromised run can install backdoors or modify build scripts. Ephemeral containers solve this: the container is destroyed after each run, and read-only filesystem mounts limit tampering with the environment. Network exfiltration: Without network isolation, a malicious command can call back to an attacker-controlled server with extracted secrets. Running the container with no network access (--network none) prevents this. The ephemeral container approach with no network access, read-only filesystem mounts, and a dedicated low-privilege user with no access to CI/CD credentials provides the strongest boundary because it combines isolation, ephemerality, and credential separation. Input validation that rejects shell commands containing semicolons or pipe characters is brittle—attackers use base64 encoding, environment variable expansion, here-docs, and many other techniques to bypass character-level filtering. Logging all commands and alerting if commands exceed a certain length is a detection control with no prevention value; short commands can be highly destructive (rm -rf /). Configuring the tool to only execute commands from a pre-approved list of test runner binaries is a stronger control than input validation but still insufficient on its own—a legitimate test runner binary can be exploited to run arbitrary code, and the container boundary prevents the blast from spreading beyond the sandbox.