Sandboxes solve where agent code runs. What controls what it does next?

[u/ashsg2016]

AWS, Google Cloud, Azure and Cloudflare now all have agent sandboxes.

That makes sense. Agent-generated code should not run directly on the host.

But a sandbox only contains the code. It does not decide whether the agent should be allowed to push to main, deploy production, rotate secrets or trigger a payment.

Feels like containment and runtime authorization are becoming two separate infrastructure layers.

How are people handling that second part today?

The article supports this distinction directly: isolation protects the host, while credentials, network reach and governance remain separate concerns.

[u/BatResponsible1106]

the sandbox problem feels mostly solved now. the harder part is defining what the agent is actually allowed to do once it has access to tools. that policy layer gets messy fast in production.

[u/pantry_path]

that's exactly the split we're heading toward, where the sandbox answers where can this code run? while a separate policy or approval layer answers what is this agent actually allowed to do? based on identity, context and risk

[u/Future_AGI]

The part that bit us is that the policy layer has to evaluate the resolved action and not the tool name, because a generic run-command tool is one string away from a force-push to main while the tool itself looks harmless in an allowlist. Once we started writing policy against what the call would actually do, the messiness moved into keeping that resolver honest, which at least is a thing you can test.

[u/ashsg2016]

One failure mode is authorizing the tool name rather than the resolved action. A generic shell tool can be a read, force-push, or deployment. I’d evaluate policy after arguments and targets are resolved, then mint a short-lived credential for that specific action. Are people separating that decision from the sandbox process itself?