secure-execution-environment

name	secure-execution-environment
description	Run agent tasks in isolated, sandboxed environments to prevent malicious or untrusted code from affecting the host system.

Skill: Secure Execution Environment

Category: Agent Security Priority: High

---

Description

This skill ensures that all tasks executed by DevinOS run inside isolated, secure environments. It prevents malicious, buggy, or untrusted code from affecting the host system, exfiltrating data, or escaping its intended boundaries.

Purpose

To protect the host system, user data, and other projects from code that the agent writes, installs, or interacts with. It provides defense in depth for every command, test, and external dependency.

Trigger

Use this skill when:

• Running untrusted code or third-party dependencies.
• Executing build, test, or install scripts.
• Running user-provided scripts or AI-generated code.
• Handling sensitive data in a multi-tenant environment.
• Setting up CI/CD or local development environments for an agent.

Context

• Host operating system and available isolation tools.
• Required resources (CPU, memory, network) for the task.
• Sensitivity of the data being processed.
• Network egress requirements.
• Policy for privileged vs. unprivileged execution.

Workflow

1. Assess risk. Classify the task: trusted internal, third-party dependency, untrusted user code, network-exposed.
2. Choose isolation level.
   • Low risk: unprivileged user + read-only mounts.
   • Medium risk: container (Docker, Podman) with limited network and no root.
   • High risk: micro-VM (Firecracker, Kata Containers) or gVisor sandbox.
3. Create the environment. Build or launch the sandbox with minimal permissions and required files only.
4. Run the task. Execute the command inside the sandbox with strict resource limits.
5. Monitor and audit. Capture logs, network activity, and file system changes.
6. Collect results. Copy only intended outputs (build artifacts, test results) back to the host.
7. Destroy the environment. Tear down the sandbox and remove temporary data.
8. Review. Check logs for suspicious behavior and record findings.

Examples

Good: Run a generated script in a container

Scenario: The agent needs to execute a user-provided Python script that installs packages.

Agent Action:

1. Runs the script inside a Docker container with a non-root user.
2. Mounts only the required input directory read-only.
3. Disables network unless explicitly needed.
4. Captures stdout and returns results.
5. Destroys the container after execution.

Bad: Run untrusted code directly on the host

Scenario: The agent executes a downloaded shell script with bash install.sh on the host.

Agent Action:

1. Refuses and runs the script inside a sandbox instead.
2. Explains the risk to the user.

Anti-patterns

• Running untrusted code as root or on the host.
• Mounting the entire host file system into a sandbox.
• Allowing unrestricted network egress from a sandbox.
• Reusing sandbox environments across different trust boundaries.
• Skipping audit logs for high-risk execution.

Verification

• The sandbox runs with minimal privileges.
• Only required files are mounted, and sensitive paths are excluded.
• Network access is restricted or disabled unless required.
• Resource limits are enforced.
• Audit logs are captured.
• The sandbox is destroyed after use.
• Cross-skill references are used (Security, Docker, Agent Self-Healing).

Cross Skill References

• Security: Threat modeling, secure defaults, vulnerability management.
• Docker: Container creation, hardening, and cleanup.
• Agent Self-Healing: Recovering from failed or compromised environments.
• Incident Response: Handling sandbox escapes or suspicious behavior.

References

• Firecracker: https://firecracker-microvm.github.io/
• Kata Containers: https://katacontainers.io/
• gVisor: https://gvisor.dev/
• Podman: https://podman.io/
• Docker security best practices: https://docs.docker.com/develop/dev-best-practices/