@bugsense Agreed on OS-level sandboxing -- the paper actually argues it is not a sandbox at all. If the host kernel is in the trust path, you have a weaker boundary, and it does nothing for the credential problem either. Our definition starts at hardware-level isolation: the agent runs in a microVM, and everything it can touch crosses a host-mediated virtio boundary.

That boundary is where the credential story changes. The token, the policy engine, and the audit log live on the host side, where the agent cannot reach them. Guardrails inside the agent context (an app-layer "are you sure" wrapper, a system prompt) share the cage with the agent -- a prompt injection can talk its way around them. Guardrails on the trust boundary cannot be talked to at all. The sandbox does not decide whether a granted API call is being abused; it guarantees the thing that decides is out of the agent's reach.

To your actual question: we do neither extreme. Capabilities are deny-by-default and granted per investigation, scoped to endpoints, not "the network". Read paths flow freely -- that is most of an investigation anyway. Mutating calls are a small set, and remediation is proposed, not executed: the mutation goes through an approval step at the boundary. So yes, human gating for mutations. It stays practical because the mutating surface is small by construction.

On shadow environments: honestly, you mostly cannot mirror domain state. You cannot fork Stripe, or a customer's prod cluster, and diff the side effects. Where the substrate supports it we use dry-run / plan-apply, and the microVMs are checkpointed per step, so the agent's own state can be rewound cheaply. An external side effect, once committed, is the one thing no sandbox rewinds. Which is exactly why we keep that set small and gated at the boundary.