AI Sandboxes Protect the Host. Runtime Authorization Protects the Business.

What a sandbox solves

Sandboxes help isolate model-generated code and the operations that often accompany it: shell commands, package installation, file operations, development servers, tests, and build processes. According to the isolation model in use, they reduce the chance that untrusted code damages the host machine or shared developer environment.

In short, sandboxes answer: where can agent-generated code run more safely?

What a sandbox does not decide

Isolation alone does not determine whether an agent may push to a protected branch, deploy to production, apply infrastructure changes, rotate credentials, initiate a payment, approve a refund, export customer records, or modify production data.

Not every sandbox exposes those capabilities. The point is different: when credentials, network access, APIs, production tools, cloud permissions, or database access are deliberately granted, a separate authorization problem appears. Containment protects the host. Authorization governs business consequences.

Containment versus authorization

These are complementary layers, not competing technologies. Cloud sandboxes also differ by platform; the comparison below uses careful wording rather than treating every implementation as identical.

BobSentry evaluates intended actions before execution and returns ALLOW, REQUIRE_APPROVAL, or BLOCK. Learn the product model on Product and the definition on What is BobSentry?.

Concrete coding-agent example

The important boundary appears when an agent moves from preparing work to changing a real system.

1. Agent writes code.
2. Agent runs tests in a sandbox.
3. Agent prepares a deployment.
4. Agent attempts a production deployment.
5. BobSentry evaluates the intended action.
6. Decision is ALLOW, REQUIRE_APPROVAL, or BLOCK.
7. The deployment may proceed only according to that result.
8. The downstream outcome is recorded separately.

The execution boundary sits before step 7. Approval authorizes the action to proceed. It does not prove that the deployment succeeded.

For coding-agent patterns in more detail, see How to Control AI Coding Agents Before They Push Code or Deploy to Production and Dev Guard.

Example action metadata

The following is an illustrative schema for discussion, not a promise of a native cloud or IDE integration.

{
  "agent_id": "coding-agent-production",
  "action": "deployment.production",
  "target": "customer-api",
  "context": {
    "repository": "customer-api",
    "branch": "main",
    "environment": "production",
    "tests_passed": true,
    "protected_branch": true,
    "change_risk": "high"
  }
}

Teams should not send complete source code, full diffs, secrets, access tokens, .env files, customer records, or unfiltered terminal logs. Prefer normalized metadata. See Developers for the sandbox evaluate path.

Beyond coding agents

The same distinction appears outside software delivery. These are examples of the pattern, not claims of deployed BobSentry integrations.

• Financial workflow: a sandbox or isolated worker prepares a payment; runtime authorization decides whether it may be submitted.
• Healthcare workflow: an isolated agent processes permitted data; runtime authorization decides whether an export or external disclosure may execute.
• Enterprise operations: an agent prepares a configuration change; runtime authorization decides whether production infrastructure may be modified.

Where the authorization boundary should sit

Stronger enforcement belongs in infrastructure that controls the consequential tool path, such as a deployment wrapper, required CI check, protected tool gateway, API middleware, customer-side execution gateway, or controlled workflow service.

Prompt instructions are not enforcement. Editor rules are not enforcement. A standalone evaluate call is advisory unless the caller respects the decision. BobSentry is strongest where it controls or gates the execution path. BobSentry does not currently ship a native AWS, Google Cloud, Azure, Cloudflare, Cursor, or MCP integration.

Failure modes

Plan for evaluation timeout, BobSentry unavailability, queued approval, missing approvers, a decision returned but ignored by the caller, and downstream failure after approval. Teams must choose fail-open or fail-closed behavior by action class. There is no single universal policy for every workflow.

What BobSentry does and does not prove

FAQ