← Back to compare hub

APort vs sandbox-only controls

Isolation limits blast radius. Authorization decides whether an action should happen at all.

Sandboxes, VM boundaries, and scoped runtimes are powerful containment primitives. They reduce the damage unauthorized behavior can cause after execution starts.

APort solves a different question: should this action be allowed in the first place? Best practice combines both layers.

Comparison pointOAP / APortSandbox / container only
Pre-action enforcementIs every sensitive action gated before execution?Yes — `before_tool_call` / shell hooks; model cannot bypass the platform layer.Contains blast radius; does not prove the action was authorized under policy.
Policy as dataNamed, versioned rules vs ad hoc checksVersioned policy packs (e.g. `system.command.execute.v1`, `mcp.tool.execute.v1`) with schemas and tests.Infrastructure policy (network, FS); not the same as per-capability business rules.
Enterprise identity & assuranceTiers that map to real-world trustAssurance levels L0–L4FIN (self-attested through KYC/financial-grade paths).Not applicable.
Audit & proofWhat can a third party verify?Signed decisions, passport digest, append-first audit logs; verifier integrates with registry.Runtime telemetry; not a substitute for per-decision proofs.
Delegation between agentsSub-agents and narrowed scopesDelegation formalism is a known gap on the roadmap; passport-level suspend is production-ready.Isolation does not express delegation semantics.
MCP & IDE scaleWhere developers actually run agents todayShipped adapters: OpenClaw, Cursor, LangChain, CrewAI, n8n, etc.; MCP-aware packs.Depends on deployment; not MCP-specific.
Latency postureTypical evaluation pathHosted API ~53–65 ms median in published benchmarks; local evaluation supported.VM/container overhead only.

Use Sandbox / container only when

  • You need filesystem/network containment for untrusted code
  • You are running high-risk workloads in isolated environments
  • You need runtime-level resource and syscall controls

Use OAP / APort when

  • You need policy-bound allow/deny before tool calls run
  • You want capability scoping by agent identity and assurance
  • You require explainable denial codes and audit semantics

Why teams choose OAP / APort

Prevents unauthorized actions, not just damage

Authorization checks happen before execution, complementing sandbox controls that operate during/after execution.

Capability model for tool calls

Policies can express who can execute which tool and under what limits, independent of runtime isolation.

Works across frameworks and IDEs

Hook-based guardrails can be applied consistently in OpenClaw, Cursor, LangChain, CrewAI, and more.