### 🔎 Phase 1: Execution Requirements & Threat Scope ### 1.1 Requirements Analysis | Category | Proposed requirement | | -------------- | ---------------------------------------------------------- | | Workload | AI-generated scripts and tests | | Languages | Python and Node.js | | Execution mode | Short-lived, non-interactive jobs | | Trust level | Untrusted code | | Data access | Current execution workspace only | | Network | Denied by default | | Tenancy | Separate workspace and sandbox per execution | | Availability | Queue-based execution with bounded concurrency | | Output | Standard output, errors, exit code and validated artifacts | | Recovery | Terminate, clean up and record final status | ### 1.2 Confirmed vs. Proposed * Given inputs: Python, Node.js, cloud deployment, run/test/inspect, workspace-only access and restricted networking. * Assumptions: Linux-based execution workers, short-lived jobs and potentially multiple users. * Proposals: Non-root execution, immutable runtime images, microVM isolation for untrusted multi-tenant workloads, external resource enforcement and independently verified cleanup. * Unresolved: Cloud provider, expected concurrent jobs, maximum execution duration, data sensitivity, budget, and whether approved packages need internet access. ### 1.3 Threat Actors and Assets | Threat | Asset at risk | | ---------------------------- | ---------------------------------------------------- | | Malicious generated code | Worker and host integrity | | Prompt injection | Execution policy and authorization | | Compromised dependency | Runtime image and workload integrity | | Infinite loops or fork bombs | CPU, memory and availability | | Malicious file operations | Workspace confidentiality and integrity | | SSRF and network scanning | Cloud infrastructure and internal services | | Cross-tenant access | Other users' files and results | | Compromised supervisor | Execution control plane | | Malicious output | Logs, downstream applications and artifact consumers | Phase 1 decision: Treat every submitted program, dependency, archive, generated file and program output as untrusted. ### 🧩 Phase 2: Trust Boundaries & Isolation Model ### 2.1 Proposed Architecture ```mermaid flowchart TD A[User or AI Agent] --> B[Request Gateway] B --> C[Authentication and Policy Engine] C --> D[Admission Scheduler] D --> E[Sandbox Provisioner] E --> F[Isolated MicroVM] F --> G[Python or Node.js Runtime] G --> H[Output and Artifact Validator] H --> I[Controlled Result Delivery] F --> J[Execution Supervisor] J --> K[Cleanup Controller] K --> L[Cleanup Verification] B --> M[Audit and Telemetry] C --> M J --> M L --> M ``` ### 2.2 Trust Boundaries * User to gateway: Authenticate requests, enforce request size limits and validate input schemas. * Gateway to policy engine: Verify user permissions, tenant identity, language and resource profile. * Control plane to execution plane: Pass only the authorized job specification and required workspace files. * Host to sandbox: Use a hypervisor-backed boundary for stronger isolation of hostile code. * Sandbox to output validator: Treat all output and artifacts as untrusted data. * Cleanup to final status: Do not report success until required cleanup and final-state checks succeed. ### 2.3 Isolation Mechanisms | Mechanism | Security purpose | Remaining risk | | ------------------------- | ----------------------------------------------- | -------------------------------------------------------------- | | Containers | Package runtime and filesystem | Shared-kernel vulnerabilities | | Linux namespaces | Separate process, mount, user and network views | Kernel attack surface remains | | Seccomp | Restrict system calls | Allowed syscalls can still be abused | | AppArmor or SELinux | Restrict permitted operations | Policy errors or incomplete coverage | | cgroups | Enforce CPU, memory and process limits | Incorrect configuration or host-level failures | | MicroVM | Separate guest kernel from host kernel | Hypervisor, device emulation and configuration vulnerabilities | | Full VM | Strong guest/host separation | Higher operational and resource cost | | Dedicated execution hosts | Reduce cross-tenant exposure | Host compromise and provisioning errors remain possible | Recommended isolation: MicroVM per execution for untrusted, potentially multi-tenant code, with guest-level restrictions and host-side resource enforcement. Containers can be used inside the microVM for additional organization, but not as the only boundary. If workload risk and budget are low, a hardened container tier may be considered after an explicit threat assessment. ### 🏗️ Phase 3: Sandbox Architecture & Component Design | Component | Responsibility | Privilege and security control | Failure handling | | ------------------- | -------------------------------- | ---------------------------------------- | ---------------------------------- | | Request gateway | Receive job requests | Authenticate; no host execution access | Reject malformed requests | | Policy engine | Authorize code execution | Read-only policy access | Fail closed | | Scheduler | Manage queues and quotas | Scheduling permissions only | Backpressure and queue limits | | Provisioner | Create isolated environments | Narrow infrastructure permissions | Roll back partial provisioning | | Image manager | Select approved runtimes | Verify image digests and signatures | Reject unapproved images | | Supervisor | Track and terminate execution | Restricted control privileges | Kill execution on lost lease | | Workspace manager | Prepare input and collect output | Job-scoped file access | Reject unsafe archives | | Network controller | Enforce egress policy | Host-level network enforcement | Deny when policy enforcement fails | | Resource controller | Apply hard quotas | Infrastructure-level resource control | Terminate on limit breach | | Output validator | Validate files and results | No execution privilege | Reject invalid artifacts | | Cleanup controller | Remove execution resources | Scoped cleanup permissions | Retry and escalate | | Audit pipeline | Record security events | Append-only or access-controlled records | Buffer safely and alert on loss | ### 3.1 Control Plane vs. Execution Plane * Control plane: Gateway, authorization, scheduler, provisioning, audit and cleanup orchestration. * Execution plane: MicroVM, guest operating system, language runtime and untrusted code. * Critical separation: Untrusted code must not be able to call privileged control-plane APIs, inspect supervisor credentials or modify security policy. ### 3.2 Component Failure Rules * Provisioning failure: reject or retry safely without leaving partial resources. * Policy service unavailable: do not start new executions. * Network enforcement unavailable: do not permit unrestricted execution. * Supervisor lost: an independent lease monitor must terminate or quarantine the execution. * Cleanup verification failure: mark the job as requiring security recovery; do not silently mark it fully cleaned. ### 🔐 Phase 4: Identity, Permissions & Capability Control ### 4.1 Execution Identity Each execution receives: * A unique execution ID and tenant association. * A non-root guest identity with no unnecessary Linux capabilities. * A private workspace and isolated process namespace. * No host credentials, cloud metadata credentials or control-plane tokens. * A minimal, explicitly constructed environment-variable set. * A read-only runtime image and bounded writable storage. Where the host needs permission to provision microVMs, that privilege stays with the provisioner and never enters the guest. ### 4.2 Permission Matrix | Resource or action | Allowed | Denied / conditional | Enforcement and test | | ---------------------- | ------------- | ---------------------------------------------- | -------------------------------------- | | Read workspace inputs | Yes | Files outside workspace denied | Mount policy; path escape test | | Write workspace output | Yes | Host paths denied | Guest filesystem; write-boundary test | | Execute Python/Node.js | Yes | Unapproved runtimes denied | Runtime selector; image test | | Run subprocesses | Conditional | Excessive process creation denied | cgroups and process limits | | Become root | No | Privilege escalation denied | Guest identity and capability checks | | Load kernel modules | No | Denied | Guest configuration and syscall policy | | Access host devices | No | Denied by default | Device and VM configuration | | Access cloud metadata | No | Denied | Host network policy; SSRF test | | Access internet | No by default | Approved egress only if justified | Network gateway and firewall test | | Read secrets | No | Job-scoped secrets only with explicit approval | Environment and mount inspection | | Modify security policy | No | Denied | Host-side authorization | | Inspect other jobs | No | Denied | Tenant isolation test | | Produce artifacts | Yes | Type, size and path restrictions apply | Output validator | | Open inbound ports | No | Explicit exception only | Network policy test | Acceptance rule: A denied action must fail at an enforceable boundary, not merely because an application or prompt says it is prohibited. ### 📁 Phase 5: Filesystem, Secrets & Network Policy ### 5.1 Filesystem Layout ```text / ├── runtime/ # Read-only runtime ├── workspace/ │ ├── input/ # Authorized input files │ ├── work/ # Temporary writable area │ └── output/ # Candidate artifacts └── tmp/ # Bounded temporary storage ``` This is a logical layout inside the guest. Host paths, mount configuration and ownership must be independently controlled. ### Filesystem rules * Mount the runtime read-only. * Create a fresh workspace for each execution. * Reject path traversal, absolute-path escapes, unsafe symbolic links and archive entries that resolve outside the workspace. * Enforce storage capacity and inode limits. * Do not mount host root directories, container runtime sockets, SSH credentials or cloud credential files. * Validate artifact paths, file types and size before delivery. * Avoid sharing writable dependency caches across tenants. ### 5.2 Secret Isolation * Do not inject general cloud credentials into execution environments. * Keep provisioning credentials in the control plane. * Construct an allowlisted process environment rather than inheriting the parent environment. * Prevent secrets from entering stdout, stderr, crash reports and telemetry. * Use scoped, short-lived credentials only if a specific approved integration requires them. * Restrict audit access and apply retention rules to potentially sensitive output. ### 5.3 Network Policy | Network destination | Default policy | Enforcement | | ------------------------ | -------------------------------------------- | ------------------------------------------ | | Public internet | Deny | Host firewall or egress gateway | | Cloud metadata endpoints | Deny | Host-side routing and firewall | | Private network ranges | Deny | Egress gateway and destination policy | | Loopback | Guest-local only; no host services | Network namespace and VM boundary | | Control-plane APIs | Deny from workload | Network segmentation | | DNS | Deny by default; approved resolver if needed | Controlled DNS path | | Package registries | Preparation stage only by default | Restricted downloader or proxy | | Inbound connections | Deny | Host firewall and VM network configuration | If external access becomes necessary, allow only explicitly approved destinations through a controlled proxy. Validate resolved IP addresses at connection time, block private and link-local ranges, defend against DNS rebinding, limit redirects and prevent direct connections that bypass the proxy. Exception requirements: Each network exception needs a business justification, a defined owner, destination scope, expiry or review date, audit record and validation test. Dependency downloads should preferably happen in a controlled preparation stage with pinned versions, integrity verification and a restricted cache. Public package availability does not establish package safety. ### ⚙️ Phase 6: Resource Budget & Fairness Numeric values below are proposed initial test settings, not universal safe limits. They must be benchmarked and adjusted before deployment. | Resource | Initial proposal | Enforcement | Breach action | | ------------------ | ---------------------------------------- | -------------------------------- | ------------------------------------------ | | CPU | 1 vCPU equivalent per job | Host scheduler and cgroups | Throttle | | Memory | 512 MiB per job | Guest and host limits | Terminate on hard limit | | Wall-clock time | 30 seconds | Independent supervisor | Kill entire execution | | CPU time | 20 seconds | OS CPU accounting and supervisor | Terminate | | Writable disk | 256 MiB | Bounded filesystem or volume | Reject further writes; terminate if needed | | Processes/threads | 64 combined, subject to platform support | PID limits and runtime policy | Deny creation or terminate | | File descriptors | 256 | OS resource limits | Deny additional descriptors | | Network | Disabled by default | Host firewall and egress gateway | Block connections | | Output | 1 MiB combined stdout/stderr | Supervisor output collector | Stop capture and terminate or reject | | Queue depth | Configurable per tenant | Scheduler | Reject or defer | | Concurrent jobs | 2 per tenant initially | Admission controller | Queue or reject | | Execution duration | No indefinite jobs | Independent deadline enforcement | Forced termination | ### 6.1 Fairness and Overload Protection * Apply per-tenant quotas and global admission limits. * Reserve host capacity for control-plane operations. * Use bounded queues and backpressure. * Include child processes in process limits. * Enforce memory, disk and network restrictions outside the untrusted program. * Prevent one tenant from consuming all execution slots. * Monitor throttling, queue wait time and repeated quota violations. Verification: Test CPU loops, memory exhaustion, excessive file creation, subprocess spawning, large output and connection floods in a dedicated test environment. Each test must prove that the limit is enforced even if the workload ignores termination requests. ### 🔄 Phase 7: Execution Lifecycle ### 7.1 State Machine ```mermaid flowchart TD A[RECEIVED] --> B[VALIDATED] B --> C[AUTHORIZED] C --> D[QUEUED] D --> E[PROVISIONING] E --> F[INITIALIZING] F --> G[RUNNING] G --> H[CAPTURING OUTPUT] H --> I[VALIDATING OUTPUT] I --> J[TERMINATING] J --> K[CLEANING] K --> L[VERIFYING CLEANUP] L --> M[SUCCEEDED] L --> N[CLEANUP_FAILED] G --> O[TIMED_OUT] G --> P[CANCELLED] E --> Q[PROVISION_FAILED] O --> J P --> J Q --> K N --> R[QUARANTINE AND ALERT] ``` ### 7.2 Lifecycle Rules * Validate the request and establish an immutable execution ID. * Authorize the user, tenant, language and resource profile. * Provision the sandbox using an approved image and isolated workspace. * Confirm that isolation, resource limits and network policy are active before execution. * Start the runtime under the restricted execution identity. * Capture bounded output without trusting its content. * On completion, timeout or cancellation, stop the complete process tree and execution environment. * Validate output files and enforce artifact restrictions. * Clean up and verify the required resources are gone. * Record the final status and audit evidence. ### Cancellation and timeout * Attempt graceful termination for a short, bounded period. * If the workload does not stop, forcibly terminate the complete execution group or destroy the microVM. * Use an independent supervisor or lease monitor so a crashed orchestrator cannot leave jobs running indefinitely. * Use idempotency keys to prevent duplicate execution when requests are retried. * Never retry a failed job automatically without checking whether it has side effects. Success condition: A valid result, a confirmed terminal execution state and successful required cleanup. If cleanup fails, return an explicit incomplete or failed status instead of claiming complete success. ### 🧹 Phase 8: Cleanup & Residual Resource Plan | Resource | Cleanup method | Verification | Failure response | | ----------------------- | ----------------------------------------------------- | ------------------------------------------------ | ---------------------------- | | Running processes | Terminate execution group or destroy microVM | Confirm no associated execution remains | Quarantine worker | | Workspace files | Delete job-scoped storage | Confirm path or volume is removed | Retry and alert | | Writable image layers | Discard ephemeral layer | Confirm backing resource is detached and deleted | Quarantine | | Mounts and namespaces | Tear down guest or sandbox | Verify resource references are released | Reconcile orphan | | Credentials | Revoke temporary grants; discard environment | Check credential lifecycle records | Escalate and revoke | | IPC and sockets | Destroy guest and scoped resources | Confirm resources are no longer reachable | Investigate | | Network connections | Terminate guest networking | Verify endpoint and lease cleanup | Block network and quarantine | | Logs and output buffers | Apply retention and delete temporary buffers | Check deletion and retention records | Restrict access | | Dependency cache | Use immutable shared cache or isolated writable cache | Verify ownership and integrity | Purge affected cache | | Cloud resources | Destroy temporary compute and storage | Reconcile with provider inventory | Retry and escalate | ### 8.1 Cleanup Verification Every resource must have an execution ID, owner, creation record and cleanup status. * Make cleanup operations idempotent. * Run periodic reconciliation against actual infrastructure resources. * Retry transient failures with bounded backoff. * Quarantine workers with unresolved isolation or cleanup failures. * Alert the responsible operator when automatic recovery fails. * Track logical deletion separately from physical storage destruction. Deleting a file does not guarantee physical erasure on every storage medium. For sensitive workloads, use provider-supported ephemeral resources and encryption-key lifecycle controls where appropriate. ### 🚨 Phase 9: Attack Scenarios & Failure Containment Risk ratings are preliminary qualitative assessments. They must be refined after the threat model and deployment environment are confirmed. | Threat | Priority | Prevention and detection | Containment and recovery | Required test | | --------------------- | -------- | -------------------------------------------- | ---------------------------------------- | ---------------------------------------------------------------------------------------------- | | Sandbox escape | Critical | MicroVM isolation, hardened host, patching | Destroy guest, quarantine host | Attempt controlled boundary violations | | Privilege escalation | Critical | Non-root identity, capability removal | Terminate guest | Verify root and privileged operations fail | | Secret theft | Critical | No inherited secrets, scoped credentials | Revoke credentials; investigate exposure | Search environment, filesystem and output | | SSRF/metadata access | Critical | Default-deny egress, host-side blocking | Block traffic and terminate if necessary | Attempt metadata and private-address access | | Cross-tenant access | Critical | Separate workspaces, guests and identities | Quarantine affected executions | Attempt access using two test tenants | | Fork bomb | High | PID limits and supervisor | Kill entire execution | Controlled process exhaustion | | Memory exhaustion | High | Hard memory limits | Terminate and recover capacity | Allocate beyond memory ceiling | | Infinite loop | High | Wall-clock deadline | Force termination | Run non-terminating test program | | Disk exhaustion | High | Storage and inode quotas | Stop writes or terminate | Fill test workspace | | Malicious dependency | High | Pinned dependencies and isolated preparation | Revoke package and rebuild | Install a harmless test package with a malicious install hook in a disposable test environment | | Output-based attack | High | Output escaping and artifact validation | Reject unsafe artifact | Submit HTML-like output and path traversal filenames | | Supervisor crash | High | Independent lease monitor | Kill or quarantine orphaned guest | Crash supervisor during execution | | Cleanup failure | High | Reconciliation controller | Retry, quarantine and alert | Inject a cleanup error | | Worker/node loss | High | Durable job records and reconciliation | Reconcile before retrying | Terminate a disposable test worker | | Dependency compromise | High | Digest verification and image revocation | Block affected versions and rebuild | Reject a deliberately mismatched digest | Residual risk: Hypervisor vulnerabilities, kernel or host misconfiguration, compromised control-plane components and supply-chain attacks cannot be eliminated by one sandbox mechanism. They require layered defenses, patching, monitoring and incident response. ### 📦 Phase 10: Runtime & Dependency Supply Chain ### 10.1 Runtime Image Policy * Maintain approved, minimal Python and Node.js runtime images. * Pin images by immutable digest. * Verify image provenance and signatures where supported. * Scan images for vulnerabilities before release. * Generate a software bill of materials where appropriate. * Use lockfiles and pinned dependency versions. * Build images in isolated CI workers. * Keep production runtime images immutable. * Patch and rebuild on a documented cadence. * Maintain a tested rollback process. * Revoke images or packages when compromise is identified. ### 10.2 Dependency Installation Decision | Strategy | Benefit | Risk or cost | | ---------------------------- | ------------------------------------------------- | ------------------------------------------------ | | Prebuilt runtime images | Predictable startup and reduced runtime access | Image maintenance | | Controlled preparation stage | Flexible packages with restricted download access | More pipeline complexity | | Install inside sandbox | Maximum package flexibility | Greater attack surface, latency and network risk | Recommendation: Prebuilt images for standard dependencies; an isolated preparation stage for approved additional packages. Do not grant arbitrary workloads unrestricted package installation or internet access. ### 🧪 Phase 11: Security Test Plan All tests below are planned. None is represented as executed or passed. | Test ID | Controlled test | Expected result | Evidence required | Severity if failed | | ------- | ---------------------------------- | --------------------------------- | ------------------------------------- | ------------------ | | ST-01 | Run valid Python script | Correct bounded output | Exit code and output | High | | ST-02 | Run valid Node.js script | Correct bounded output | Exit code and output | High | | ST-03 | Read a permitted workspace file | Read succeeds | File access record | Medium | | ST-04 | Attempt access outside workspace | Access denied | Denial evidence | Critical | | ST-05 | Attempt host metadata access | Connection blocked | Network policy logs | Critical | | ST-06 | Attempt unauthorized secret access | No secret available | Environment and filesystem inspection | Critical | | ST-07 | Exceed memory quota | Execution contained | Resource telemetry | High | | ST-08 | Run infinite loop | Deadline enforced | Termination timestamp | High | | ST-09 | Spawn excessive processes | PID limit enforced | Resource-limit evidence | High | | ST-10 | Fill workspace storage | Disk quota enforced | Storage telemetry | High | | ST-11 | Cancel active execution | Entire execution terminates | Process and VM state | High | | ST-12 | Crash supervisor | Orphan recovered | Lease and reconciliation logs | Critical | | ST-13 | Inject cleanup failure | Failure surfaced and escalated | Cleanup event and alert | Critical | | ST-14 | Run two tenant jobs concurrently | No cross-access | Isolation test results | Critical | | ST-15 | Supply unsafe artifact archive | Archive rejected | Validator logs | High | | ST-16 | Use mismatched image digest | Image rejected | Image verification log | Critical | | ST-17 | Attempt unauthorized egress | Traffic blocked | Firewall or proxy logs | Critical | | ST-18 | Simulate worker loss | Resources reconciled before retry | Scheduler and infrastructure records | High | ### 11.1 Test Acceptance Criteria A test passes only when: * The expected security property is observed. * The enforcement point is identified. * Evidence is retained with the execution ID and test version. * The result is repeatable under the documented test conditions. * No unexpected cross-boundary access occurs. * The failure and recovery behavior matches the design. Release blocker: Any failed critical isolation, authorization, secret-protection, resource-enforcement or cleanup test blocks production deployment. ### 📊 Phase 12: Observability & Incident Response ### 12.1 Required Audit Events Har execution ke liye ye records capture hone chahiye: * Execution ID, tenant ID and request correlation ID. * Runtime version and image digest. * Authorization decision and policy version. * Execution start, completion, cancellation and timeout. * CPU, memory, storage and output usage. * Network-denial events and suspicious connection attempts. * Process termination status. * Artifact validation result. * Cleanup result and orphan-reconciliation status. * Supervisor, worker and provisioning failures. ### 12.2 Metrics and Alerts | Metric | Proposed alert condition | Response | | --------------------------- | ------------------------------------------ | ------------------------------------ | | Sandbox startup failures | Rate exceeds calibrated baseline | Investigate provisioner | | Memory quota violations | Repeated violations per tenant | Review workload and quota | | Unexpected network attempts | Any confirmed prohibited access | Investigate and contain | | Cleanup failures | Any unresolved cleanup failure | Quarantine affected worker | | Supervisor heartbeat | Missing beyond configured deadline | Recover or terminate execution | | Cross-tenant access | Any confirmed unauthorized access | Critical security incident | | Queue saturation | Admission capacity exhausted | Apply backpressure | | Audit pipeline failure | Required audit records cannot be persisted | Restrict new executions as necessary | Thresholds require calibration; these are proposed alert policies, not measured baselines. ### 12.3 Incident Response * Detect and classify the security event. * Identify affected executions, tenants, workers and artifacts. * Terminate or quarantine affected sandboxes. * Revoke exposed credentials and block compromised images if required. * Preserve relevant audit evidence while restricting access to sensitive data. * Reconcile infrastructure resources and investigate possible cross-tenant impact. * Restore service only after required checks pass. * Document the root cause and add regression tests. ### ⚖️ Phase 13: Architecture Options & Trade-Offs | Architecture | Isolation | Operational burden | Best fit | | ----------------------------------- | -------------------------------- | --------------------------- | ---------------------------------- | | Hardened containers | Moderate; shared host kernel | Lower | Lower-risk workloads | | Containers with layered OS controls | Improved defense in depth | Moderate | Controlled execution environments | | Dedicated sandbox workers | Reduces shared-host exposure | High | Sensitive or high-risk workloads | | MicroVM per execution | Stronger guest/host boundary | Moderate to high | Untrusted, multi-tenant code | | Full virtual machine per job | Strong isolation potential | High | Strict separation requirements | | Managed sandbox service | Depends on provider architecture | Lower infrastructure burden | Teams seeking managed execution | | Hybrid isolation tiers | Varies by workload risk | High policy complexity | Mixed trust and sensitivity levels | Actual isolation strength depends on implementation, configuration, patching and the provider's threat model. No benchmark results are assumed here. ### 13.1 Final Architecture Decision Recommended: MicroVM-based execution with layered guest and host controls. Reasons: * Generated code is untrusted. * Python and Node.js can execute arbitrary programs and spawn processes. * Workspace-only access requires enforceable filesystem boundaries. * Restricted networking requires host-side enforcement. * Independent cleanup and resource accounting are necessary. Alternatives may be reconsidered if testing shows a hardened container tier adequately satisfies the documented risk requirements or if a managed service provides stronger verifiable guarantees at lower operational cost. ### Performance benchmarks required * Cold and warm sandbox startup latency. * Throughput under concurrent workloads. * Memory overhead per isolated execution. * CPU contention and queue latency. * Cleanup duration and orphan-recovery time. * Cost per successful execution. * Failure rates under worker and supervisor loss. ### 📝 Phase 14: Architecture Decision Records | ADR | Decision | Rationale | Reconsider if | | ------ | --------------------------------- | -------------------------------- | ------------------------------------------------- | | ADR-01 | MicroVM per untrusted execution | Stronger guest/host separation | Risk assessment supports a simpler tier | | ADR-02 | Default-deny networking | Limits SSRF and exfiltration | A documented integration requires access | | ADR-03 | Non-root workload identity | Limits privilege | A verified requirement demands an exception | | ADR-04 | Immutable runtime images | Improves reproducibility | A controlled runtime-update process is introduced | | ADR-05 | Hard resource quotas | Contains runaway jobs | Benchmarking requires adjusted budgets | | ADR-06 | Independent cleanup controller | Recovers orphaned resources | A replacement provides equivalent verification | | ADR-07 | Controlled dependency preparation | Reduces runtime network exposure | Workloads require a separately approved model | | ADR-08 | Auditable policy decisions | Enables investigation | Alternative evidence meets the same requirements | Any exception must have a documented owner, scope, expiry or review date, and compensating controls. ### 🚀 Phase 15: Implementation Task Graph Implementation should follow this dependency order. TASK-01: Requirements and threat model P0 Confirm tenancy, cloud provider, budget, workload duration and data sensitivity. Acceptance: Approved requirements and documented threat model. TASK-02: Policy and authorization P0 Implement request validation, tenant authorization and default-deny decisions. Acceptance: Unauthorized jobs are rejected and decisions are audited. TASK-03: Sandbox provisioning P0 Create isolated microVMs with approved images and restricted guest configuration. Acceptance: Host-boundary and image-integrity tests pass. TASK-04: Resource and network enforcement P0 Configure hard limits, network denial, output caps and storage quotas. Acceptance: Resource exhaustion and prohibited-network tests pass. TASK-05: Execution supervisor P0 Implement deadlines, process-tree termination, cancellation and idempotency. Acceptance: Timeout and supervisor-crash tests pass. TASK-06: Output validation and cleanup P0 Validate artifacts, destroy ephemeral resources and reconcile orphans. Acceptance: Cleanup failures are detected, retried and escalated. TASK-07: Audit and incident response P1 Configure telemetry, alerts, retention and incident procedures. Acceptance: Test incidents produce actionable audit evidence and alerts. TASK-08: Staging validation and release P0 Run adversarial tests, benchmark capacity and validate rollback. Acceptance: All critical tests pass with retained evidence and approved residual risks. ### Deployment Stages * Implementation-ready: Architecture, policies and acceptance tests are approved. * Staging-validated: Security tests and performance benchmarks have been executed, with evidence recorded. * Production-approved: Release gates pass, incident response is ready, operational ownership is assigned and residual risks are formally accepted. A completed design alone does not establish production readiness. ### ⚠️ Phase 16: Risk Register & Unresolved Decisions | Risk or open question | Priority | Required decision or action | | ------------------------------------ | -------- | ------------------------------------------------- | | Cloud provider unknown | High | Select provider and verify isolation capabilities | | Expected concurrency unknown | High | Benchmark and set admission quotas | | Tenant sensitivity unknown | Critical | Confirm isolation tier and tenant boundaries | | Egress requirements unknown | High | Identify required external integrations | | Execution duration unknown | Medium | Benchmark realistic workloads and set deadlines | | Resource budget unconfirmed | High | Estimate infrastructure cost and validate limits | | Cleanup evidence unavailable | Critical | Implement reconciliation and failure injection | | Hypervisor or host vulnerability | High | Establish patching and incident procedures | | Dependency compromise | High | Implement integrity verification and revocation | | Audit retention requirements unknown | Medium | Define retention, access and deletion policy | These priorities are preliminary; likelihood and impact must be reviewed against the actual deployment. ### 🏆 Final Definition of Done Use this checklist before production approval. * Least-privilege execution identity enforced. * Host/guest isolation verified. * Cross-execution and cross-tenant access tests passed. * Filesystem and secret boundaries verified. * Default-deny network policy tested. * CPU, memory, process, storage and output limits enforced. * Complete process-tree termination verified. * Timeout and cancellation recovery tested. * Cleanup verification and orphan reconciliation tested. * Runtime images and dependencies verified. * Security regression tests integrated into CI. * Policy decisions and lifecycle events audited. * Alerts and incident response tested. * Operational owners and escalation paths assigned. * Residual risks documented and formally accepted. * Release-blocking failures resolved with supporting evidence. ### ✅ Recommended Implementation Sequence Requirements → Policy Engine → MicroVM Provisioning → Resource and Network Controls → Supervisor → Output Validation → Cleanup Verification → Security Testing → Staging Benchmarks → Production Approval. Production blockers: Unverified isolation, unauthorized resource access, unenforced hard limits, secret exposure, incomplete termination, unresolved cleanup failures or missing critical security-test evidence. This blueprint provides a concrete starting design for an AI-agent code-execution sandbox. The next step is implementation and evidence-based validation, not assuming that the architecture is already secure.