Agentic Execution Environment

Where AEE fits in the seven-layer stack

Core execution environment components

AEE versus agent framework

An agent framework expresses prompts, tools, handoffs, and reasoning graphs. An AEE supplies the execution boundary around that work: isolation, authority, resource control, logging, and recovery.

AEE versus sandbox

A sandbox is one component. AEE adds lifecycle, policy, secret handling, tool brokerage, audit, replay, approval, and side-effect control around the sandbox.

Threat model shift for autonomous agents

Autonomous agents can consume untrusted data, infer instructions from it, call tools, write state, and continue across turns. That shifts risk from static code behavior to delegated authority and dynamic intent.

Isolation technologies: process sandbox, container, gVisor, Firecracker, Kata, microVM

Isolation should match trust level. Process sandboxes and containers may be enough for trusted workflows; untrusted or third-party agents often require stronger microVM or userspace-kernel boundaries.

Snapshotting, pausing, resuming, checkpointing, and copy-on-write forks

Long-running agent sessions need state without leaving uncontrolled machines running forever. Snapshots support replay, forked exploration, and recovery.

GPU and accelerator access inside sandboxes

GPU access raises isolation and scheduling complexity. AEE designs must account for passthrough, mediated devices, quota, tenant isolation, and accelerator memory leakage.

Lifecycle management: spawn, pause, resume, fork, kill, archive

AEE owns the lifecycle verbs. The model can request continuation, but the runtime decides whether a session may keep consuming resources.

Deterministic control hooks

Pre-tool, post-tool, session-start, config-change, and approval hooks keep enforcement outside the model prompt.

Tool brokerage and side-effect classification

Read-only tools, reversible writes, irreversible writes, external sends, and financial or physical actions need different approval and idempotency rules.

Opaque secret brokers

Raw API keys should not enter the agent environment. Handles let the runtime sign outbound requests without exposing secrets to code or prompt context.

Declarative permission manifests

Tools and agents should declare filesystem, network, process, environment, camera, microphone, and API scopes before execution.

Data flow control and privacy accounting

Data that enters a sandbox should have task-scoped egress rules. Sensitive outputs should not be returned to the model unless needed.

MCP security and Code Mode execution

MCP standardizes tool access but is not a trust boundary. Code Mode can reduce context exposure when tool calls are executed inside a bounded sandbox with progressive disclosure.

A2A, ACP, ANP, DID, VC, and inter-agent identity

Multi-agent work needs discovery, authentication, message provenance, and agent identity. Credentials should be evaluated by the runtime, not inferred from prompt text.

TEEs and remote attestation

Trusted execution environments can help prove which sandbox image is running before sensitive workloads are admitted, where hardware support and threat model justify the complexity.

Observability and audit trail

AEE logs should capture proposed action, evaluated policy, final action, output, egress, resource use, human approvals, and replay identifiers.

Failure modes

• Prompt injection
• Tool misuse
• Arbitrary code execution
• Sandbox escape
• Data exfiltration through allowed tools
• Secret exposure
• Infinite loops
• Budget exhaustion
• Confused deputy
• Memory poisoning
• Cross-agent spoofing
• Duplicate side effects after retry
• Unreviewable traces
• Unbounded filesystem writes
• Unsafe egress

Evidence and metrics

• Sandbox startup time
• Resume time
• Snapshot size
• CPU/RAM/GPU quota usage
• Tool authorization denies
• Egress blocks
• Secret broker hits
• Policy hook latency
• Approved versus rejected actions
• Runaway loop interventions
• Replay completeness
• Audit event coverage
• Incident recovery time

Implementation checklist

• Classify each tool by side-effect risk.
• Keep authorization outside the prompt.
• Use opaque secret handles.
• Log every proposed and executed action.
• Design idempotency before enabling retries.

Common mistakes

• Treating the model’s tool list as a permission system
• Passing raw API keys into the agent environment
• Assuming Docker is sufficient for untrusted agents
• Letting the model decide whether it is authorized
• Retrying side-effecting actions without idempotency
• Logging only final outputs instead of tool/action traces
• Treating MCP as a trust boundary
• Ignoring outbound network paths
• Allowing persistent writable state without review

Related pages

Implementation blueprint

The v3.5.0 continuation adds a deployable implementation lens for this category. Treat the page definition as architecture guidance, then test the concrete boundary through contracts, telemetry, rollback, and review records.

AEE action decision record

This compact example is not a mandatory schema. It shows the kind of typed boundary record that should exist before the runtime term appears in production documentation.

{"runtimeType":"AEE","agentSession":"sess_20260624_001","proposedAction":"write_file","policyDecision":"approval_required","secretMode":"opaque_handle","idempotencyKey":"aee-write-001"}

Maintenance record