Warning signs include local files being modified outside the expected workspace, unexpected browser activity on the developer desktop, credentials appearing in logs or temp files, and network calls leaving through paths that were never approved. A weak sandbox also makes it hard to review exact commands and HTTP requests, which means you cannot reliably tell whether the agent stayed inside its intended boundary.
What shows a sandbox is leaking side effects?
A sandbox is failing when the agent can still affect state outside the intended boundary, especially if you see host files changing, browser sessions behaving as if the agent is using a real desktop, or secrets appearing where they should never be written. The key question is not whether the task finished, but whether every observable side effect stayed inside the containment model.
One useful test is whether the sandbox leaves you with a precise and reviewable action trail. If you cannot reconstruct the exact commands, network requests, filesystem writes, and browser actions, then the sandbox may be functionally porous even if it looks isolated on paper.
What the strongest warning signs usually look like
Unwanted side effects are easiest to spot when they escape the agent’s declared workspace. That can include modified local files outside the approved directory, downloads or temp files that persist after the run, unexpected use of the developer’s signed-in browser profile, or outbound requests that take an unapproved path. These are not just hygiene issues, they are evidence that the boundary is not holding.
Another warning sign is credential exposure. If tokens, cookies, API keys, or session material show up in logs, scratch space, clipboard history, or browser state, the sandbox is not just leaking data, it is leaking authority. At that point the agent may have enough residual access to repeat actions long after the original run should have ended.
Approval gaps are equally important. If the system allows tool calls, file writes, or network access without explicit per-action review, the containment story depends on policy, not on isolation. AI Agent Authorisation Guide is useful here because it frames agent access as a series of decisions that should be bounded by scope and approval, not granted as a blanket capability.
How to tell whether the sandbox is truly containing the agent
The practical test is whether the sandbox can be audited after the fact and still prove where the agent did and did not act. A sound setup should make it easy to inspect command history, HTTP requests, file diffs, and external connections without ambiguity. If you need to infer containment from the absence of obvious damage, the control is too weak.
Good containment also means the agent cannot quietly inherit the operator’s ambient sessions. Browser isolation, profile separation, and explicit confirmation for sensitive actions matter because many failures start when an agent drives a real desktop or authenticated browser state rather than a disposable one. Browser and Computer-Use Agent Security Guide covers exactly this class of leakage, where a sandbox boundary is undermined by session reuse and desktop reach.
When the environment includes tools, plugins, or MCP-style connectors, inspect whether the sandbox actually blocks unintended credential reach and outbound calls. MCP Security Guide is relevant because tool access and token handling often create a false sense of isolation if the agent can still touch local credentials or forward requests through an untrusted bridge.
Risk and Threat Considerations
When a sandbox does not reliably contain side effects, the risk is not limited to one bad run. The same weakness can expose files, sessions, secrets, and network destinations across repeated tasks, which turns a local execution issue into a broader compromise path. In agentic systems, that can create real blast-radius problems because the agent may continue acting with the authority it should have lost.
Failure mechanism: The sandbox boundary is incomplete, so the agent can write to host state, reuse authenticated browser context, or send requests through uncontrolled channels while appearing to remain contained.
Impact: Data leakage, credential exposure, unauthorized external access, and difficult-to-investigate actions can follow, especially if logs and audit trails do not preserve enough detail to prove what happened.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent side effects often signal privilege escaping the sandbox boundary. |
| ASI02 — Tool Misuse | Unexpected file, browser, or network actions are classic tool misuse signals. | |
| ASI10 — Rogue Agents | A sandbox failure can let an agent act beyond its intended control plane. | |
| Recommendation — Constrain agent permissions per action and revoke any capability that escapes its intended boundary. Restrict tools to explicit scopes and review every nontrivial action path. Add containment checks and kill switches for any agent that escapes approved side effects. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Secrets appearing in logs or temp files indicate containment and exposure failures. |
| NHI-05 — Overprivileged NHI | If the agent can alter host state or external paths, its access is too broad. | |
| Recommendation — Prevent secret material from entering logs, temp files, or shared workspace state. Reduce agent permissions to the minimum needed for each task and environment. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | The question hinges on whether the sandbox leaves a reviewable action trail. |
| AC-6 — Least Privilege | Sandbox leakage often means the agent retained access beyond its task scope. | |
| SC-7 — Boundary Protection | Side effects outside the workspace indicate boundary controls are not holding. | |
| Recommendation — Log the exact commands, requests, and file actions needed to reconstruct agent behavior. Limit each agent run to the smallest access set that still completes the task. Enforce network and host boundaries that block unauthorized outbound paths and writes. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | A weak sandbox is hard to review if logs do not capture exact actions. |
| Recommendation — Record sufficient detail to reconstruct requests, writes, and failures without ambiguity. | ||
Practitioner Guidance
What to verify: Confirm that the sandbox enforces filesystem, browser, and network separation at the level of observable side effects, not just process boundaries. If you can only test by running a task and hoping nothing escaped, the control is not mature enough for sensitive workflows.
Common mistake: Treating “no obvious damage” as evidence of safety. A sandbox is only as good as its ability to prevent and reveal boundary crossings, so lack of visible breakage is not the same as containment.
What good looks like: Every command, file write, browser action, and outbound request is attributable, reviewable, and confined to an approved workspace or account state. If the agent touches anything outside that scope, treat the sandbox as failed until proven otherwise.
Practitioner takeaway: The real test is not whether the agent can run, it is whether you can prove that every side effect stayed inside the intended trust boundary and was visible enough to stop, review, and revoke if needed.