A Sandbox Is Not a Decision Boundary

The new agent stack has a favorite word: sandbox.

This week, Google introduced Managed Agents in the Gemini API, with an Antigravity agent that can reason, use tools, execute code, browse the web, and manage files inside an isolated Linux environment. OpenAI is pushing Codex into hybrid and on-prem enterprise environments. LangChain is expanding runtime infrastructure around agent streams, interpreters, auth proxies, and sandboxes.

The industry is solving where the agent runs.

Production will fail on what the agent is allowed to decide.

A sandbox can contain an agent. It cannot tell whether the action is valid, scoped, current, and accountable.

Execution boundary vs decision boundary

A sandbox is an execution boundary.

It limits what a process can touch: files, network access, credentials, shells, browsers, memory, and system calls. Without execution isolation, every autonomous agent is a loaded shell with a language model attached.

But a sandbox answers a technical question:

Can this agent run here without breaking the environment around it?

It does not answer the production question:

Should this agent take this action, in this business context, with this evidence, under this policy, right now?

That is a decision boundary.

Boundary	Question it answers	Failure it catches	Artifact it produces
Sandbox	Can the agent run safely here?	Host compromise, file leakage, tenant escape, unsafe system access	Execution log
Decision boundary	Is this action valid now?	Wrong refund, stale KYC decision, invalid pricing override, scoped data leak	Causal decision trace

That is the difference between containment and accountability.

If an agent approves the wrong refund, the sandbox did not fail. If it sends the wrong renewal email to the wrong account, the sandbox did not fail. If it updates a CRM field using stale entitlement data, the sandbox did not fail.

The agent stayed inside its technical box.

The decision escaped its business boundary.

Three actions a sandbox cannot validate

Managed agents make autonomy easier to operate. A team can define instructions, tools, data, skills, and runtime behavior without rebuilding the harness. The platform handles provisioning. The developer focuses on behavior.

But when platforms make agents easier to run, they also make agent action easier to scale. The hard failures move from machine isolation to decision legitimacy.

1. Refund approval

A customer support agent has a valid token for the payments API. It runs in a secure sandbox. It calls an approved refund tool. Technically, nothing broke.

But the customer is outside the return window. The entitlement changed this morning. The order was partially fulfilled. A regional exception policy applies only to enterprise accounts, not to this account.

A sandbox can prove the refund call was contained. It cannot prove the refund was applicable.

2. KYC screening

A financial services agent reviews a customer file. It can read sanctioned-party data, beneficial ownership records, onboarding notes, and jurisdiction rules. The workflow completes.

The problem is applicability and temporal validity. Which jurisdiction governs this entity? Which policy version was active? Which contradictory source wins? Which threshold requires human review?

A sandbox only contains the process that guessed at them.

3. CRM and account changes

A revenue operations agent can update Salesforce. It runs in a managed environment, uses a scoped credential, and calls only the account-update tool.

Still, it may assign the wrong owner, expose a field to the wrong team, trigger renewal before legal review, or overwrite a contract status superseded by a private amendment.

Every one of those failures can happen while the sandbox is working perfectly.

The failure is missing pre-execution enforcement.

Access is not authority

Most teams use the same word for two different things.

Technical scope means what systems an agent can reach: Salesforce, the data warehouse, Jira, billing, support, finance.

Decision scope means what the agent is allowed to decide in a particular situation. Can it approve this refund for this customer under this policy? Can it expose this field to this recipient? Can it modify this account after this contract state changed? Can it escalate without human review?

Sandboxes help with technical scope. Identity systems help with technical scope. API gateways help with technical scope.

They do not, by themselves, model decision scope. They usually treat authority as access.

Enterprise authority is contextual. It depends on the customer, policy, time, contract state, jurisdiction, agent role, and decision being made.

That is why the context graph glossary separates scope isolation, applicability, policy-as-code, pre-execution enforcement, and causal decision trace. They are not decorative terms. They are the missing primitives between "the agent can do this" and "the agent should do this now."

This is the same pattern The Context Graph covered in MCP Solved the Pipes. Who Solves the Water Quality?. MCP made connection cheap. Managed runtimes make execution cheap. Both move the bottleneck one layer up.

Once an agent can connect to tools and run in a managed environment, the hard question becomes the one no sandbox can answer:

What context makes this action legitimate?

Not possible. Legitimate.

The before layer

Monitoring cannot fix this after the fact.

A trace can show that the agent cancelled the order, which tool was called, which prompt was active, which files existed, and which API returned a response.

That is useful for debugging.

It is not enforcement.

The control point has to sit before the action reaches the external system. Before the email is sent, the refund is approved, the database mutation commits, or the CRM update becomes the source of truth.

That is the role of pre-execution enforcement.

The agent proposes an action. The decision layer evaluates it against structured context:

• Is the relevant data current?
• Does this rule apply to this situation?
• Is the agent operating inside the correct decision scope?
• Is there a superseding policy?
• Is a human approval threshold crossed?
• Can the system produce a causal decision trace if the action is approved?

If the answer fails, the action is blocked, escalated, or rerouted. If it passes, the action executes with a replayable record of why it was allowed.

That is not a better sandbox. It is a different boundary.

The architecture this implies

The agent stack now has four distinct layers:

Layer	Function	Example primitive
Transport	Connect the agent to tools and data	MCP, APIs, connectors
Execution	Run the agent safely	Sandbox, worktree, browser, remote environment
Decision	Validate whether the proposed action is allowed	Decision context graph
Reasoning	Propose the next action	LLM, planner, agent harness

Most teams are buying layers 1, 2, and 4: more connections, better runtimes, stronger models.

Layer 3 is where production accountability lives.

This is where a decision context graph becomes the business boundary around the managed runtime. It validates context before action, checks applicability before tool calls, enforces scope at the level of decision, and records why an action was approved, blocked, escalated, or rerouted.

Rippletide is one reference implementation of that pattern: a runtime layer that evaluates agent decisions before they hit production systems. The important architectural point is broader than any one product. As agents become managed, persistent, and easier to deploy, the decision boundary becomes more important, not less.

The production question is whether those actions can be governed before they become real.

The test

Ask one question about any managed agent deployment:

If the agent is technically allowed to do something, what prevents it from doing the wrong thing for the current business context?

If the answer is "the sandbox," the system is confusing execution isolation with decision governance.

If the answer is "the prompt," the system is trusting instructions where it needs enforceable policy.

If the answer is "we monitor it," the system is accepting detection where it needs prevention.

The answer has to be structural.

Managed agents are the new runtime. Sandboxes are the new execution boundary. The decision context graph decides what reaches the real world.

Without it, the agent may be perfectly contained and still perfectly wrong.

That is the category mistake enterprises cannot afford to make. The sandbox protects the machine. The decision boundary protects the business.

---

The Context Graph is a weekly newsletter for AI engineers building production agents. Read the glossary of agent decision infrastructure for the vocabulary behind context graphs, pre-execution enforcement, accountable agents, and causal decision traces.