MAQPNADocs

How MAQPNA compares#

Two comparisons come up first: containers versus sandboxes, and agent frameworks versus a runtime.

Containers versus sandboxes#

Containers were designed for trusted code from CI running as stateless replicas. Agents are the opposite: long-lived, stateful sessions running code an LLM wrote a moment ago, calling tools and other agents on behalf of a person.

Classic container workload Agent session in a MAQPNA sandbox
Code Trusted, built in CI Untrusted, generated at runtime
Kernel boundary Shared host kernel (runc) gVisor user-space kernel, a microVM guest kernel or a confidential VM; never plain runc
Lifecycle Stateless replicas (Deployment) One sandbox per session, owned by the AgentSession, with TTL, suspend, resume and fork
Start time Seconds, cold Warm pools with late binding for fast starts
Egress Usually default-allow Default-deny; only DNS and the gateway
Identity A service account shared by all replicas A short-lived token per session naming the agent, the person it acts for and its scopes; no service-account token in the pod
Credentials Mounted secrets, long-lived None in the sandbox; the gateway injects upstream credentials
Authorisation Kubernetes RBAC on the API server A policy decision on every tool, model and egress call
Logs Mutable, for debugging A tamper-evident ledger, for evidence 
flowchart LR
    subgraph C["Plain container"]
      C1["agent code"] --> C2["host kernel"]
      C1 --> C3["any destination<br/>(default-allow egress)"]
      C4["long-lived API keys<br/>in env or volume"] --> C1
    end
    subgraph S["MAQPNA sandbox"]
      S1["agent code"] --> S2["gVisor, microVM or<br/>confidential VM"]
      S1 --> S3["MAQPNA gateway only"]
      S4["15-minute scoped<br/>session token"] --> S1
      S3 --> S5["policy · DLP · approvals<br/>budgets · audit ledger"]
    end

MAQPNA does not reinvent the sandbox: it builds on the upstream kubernetes-sigs/agent-sandbox project, gVisor, Kata Containers with Firecracker and Confidential Containers, and adds trust tiers, delegated identity, policy enforcement and evidence on top.

An agent framework versus a runtime#

An agent framework (LangGraph, CrewAI, the OpenAI Agents SDK, the Claude Agent SDK, the Vercel AI SDK) decides what the agent does: prompts, planning, tool selection, memory. A runtime decides where it runs and what it is allowed to do. MAQPNA is a runtime.

Concern Agent framework MAQPNA
Prompting, planning, tool choice Yes No
Where the code runs and how it is isolated No Sandbox per session, trust tiers
Who the agent acts for Application convention Signed identity with the person in act
Whether a tool call is allowed Optional in-process guardrails the agent could bypass Enforced outside the agent, at the gateway
Human approval Optional, in-process Approvals with four-eyes, separation of duties and user approval (CIBA)
Stopping a misbehaving agent Kill the process Kill switch across the installation; sessions suspended or terminated
Proof afterwards Application logs Hash-chained ledger with signed checkpoints

The two work together. Your agent keeps its framework and points its MCP client at MAQPNA_TOOL_<NAME>_URL and its OpenAI-compatible client at MAQPNA_MODEL_ENDPOINT. The MAQPNA SDKs (Python, TypeScript, Go) add token handling, approvals, result reporting and adapters for LangChain and LangGraph, CrewAI, the OpenAI Agents SDK, the Claude Agent SDK and the Vercel AI SDK. The same code runs under maqpna dev on a laptop and in a cluster.

Because enforcement happens outside the agent process, a prompt-injected agent cannot switch it off: it can only ask the gateway, and the gateway decides.

What you see#

maqpna dev run -- python agent.py runs an unmodified agent under a session identity, with MAQPNA_GATEWAY_URL, MAQPNA_TOKEN and MAQPNA_TOOL_<NAME>_URL set; maqpna dev timeline --last then shows every call it made and the decision on it. See the developer loop and maqpna dev run.