/learn/agent-execution-boundary
What is an agent execution boundary?
An agent execution boundary is the isolation layer that an agent's risky work runs inside — the place where you decide what the code can touch, and the place that produces evidence of what it did. It matters now because every other control point an enterprise built assumes a human is doing the work.
The short version
/learn/why-now
Every control point assumes a human
Enterprise security is a stack of control points, each built for the interface of its era. Read them in order and the pattern is hard to miss: each one instruments a place where a person acts.
- 1990s
Network perimeter
Firewalls, IP and port rules at the edge of a building
The work never crosses the perimeter — it starts inside a cloud account.
Enforced for human workPasses through unseen - 2000s
Endpoint
Agents on managed laptops, disk encryption, process rules
There is no laptop. Nothing to install an endpoint agent on.
Enforced for human workPasses through unseen - 2010s
SaaS session
SSO, CASB inspection, DLP on uploads and downloads
The agent authenticates with a token and calls the API directly.
Enforced for human workPasses through unseen - 2020s
Browser
Rendered-page policy, copy/paste and download control
Headless work renders no page. There is nothing to instrument.
Enforced for human workPasses through unseen - Now
Execution boundary
The isolation the agent's code runs inside, and what it may reach
The agent's work has to run somewhere. That somewhere can be yours.
Enforced for human workEnforced for agent work
→ passes through unseen · ✓ enforced
None of these controls are broken. They enforce exactly what they were built to enforce. They just sit on a path the agent does not take — it authenticates with a token, calls an API, and does the work without rendering a page or touching a managed device.
/learn/where-it-sits
Where the boundary sits
The execution boundary is not a replacement for your agent framework or your orchestrator. It is a layer underneath both — the two of them decide what to do, and it decides what that work is allowed to touch.
Agent brain
ADK · LangGraph · CrewAIDecides what to do next.
App runtime
Cloud Run · Kubernetes · your APIRuns the agent loop and holds the conversation.
Execution boundary
NeuronEdge EnclaveRuns the risky work in isolation and governs what it can reach.
Evidence layer
Audit chain · attestation · sealed snapshotsRecords what happened in a form a reviewer can check.
run the agent anywhere · execute the risky work in the enclave
/learn/what-it-answers
Four questions a boundary has to answer
A boundary earns the name by answering these about work that already ran. If a layer cannot answer all four, it is a sandbox, not a control point.
What ran?
The exact command, in a workspace with a known kernel and rootfs, both verified against a pinned digest at install.
What could it reach?
Egress is governed at the boundary, so the answer is a policy you set rather than whatever the code decided to open.
What is left over?
The workspace is destroyed on teardown. Snapshots are signed, so a restored state is the state you captured.
Who says so?
A signed, append-only audit chain, plus attestation evidence — with a claim ceiling we publish rather than imply.
/learn/claim-ceiling
What this does not cover yet
The control-point thesis is where this is going. It is worth being precise about how far the boundary reaches today.
The host operator is still in the trusted set
So: the control-point thesis is the destination, and the boundary described here is the as-built waypoint. When you self-host, the host operator is you — which is the whole reason the runtime is Apache-2.0 and runs on a single machine you own.
Read the threat model before you believe any of this.
The boundary is only worth what its published limits say it is. The threat model is where those limits live.