When an agent decides to call a tool, something real executes. Code runs. A network request fires. A query hits a database. The agent reasoned its way to that decision using inputs it doesn't fully control: a user message, a retrieved document, the output of a previous tool, any of which could be carrying instructions placed there by an attacker. The moment of execution is where a probabilistic decision becomes an irreversible side effect. If that moment isn't contained, the agent's blast radius is the full reach of whatever just ran.
Sandboxing is how you contain it. The principle is deny-by-default: the execution environment grants nothing unless explicitly permitted, and everything crossing its boundary is inspected. A misbehaving or hijacked tool call should fail closed and quietly. It should not phone home, not run forever, and not carry sensitive data out the side door.
The mechanism: what "running a tool" actually involves
A tool call isn't an abstraction. It's a process, or a function invocation that triggers network and system activity, with inputs the agent chose and outputs that flow back into the agent's context for its next decision. Three things are in play, and each is a place to lose control:
- The inputs the agent supplies to the tool. If the agent was injected, these arguments may be hostile: a query crafted to exfiltrate, a URL pointed at an attacker's server, a payload designed to abuse the tool.
- The execution itself, what the tool does when it runs. Does it reach the network? How long can it run? What can it access?
- The outputs the tool returns, which become part of the model's next prompt. Tool output is untrusted input to the model, and it's a prime vector for the next round of injection or for sensitive data leaking into a context window where it doesn't belong.
A sandbox is the boundary you draw around execution so that all three are constrained and observed. Without it, a single tool call can initiate an outbound connection to anywhere, run unbounded, and pass arbitrary data in and out. That is exactly the freedom you don't want a non-deterministic, injection-susceptible system to have.
Why this is hard: the injection problem doesn't respect your firewall
The defining difficulty of agentic execution is prompt injection. Hostile instructions hide in content the agent legitimately processes: a web page it was asked to summarize, an email in the inbox it's triaging, a record in a database. The model, doing its job, reads that content and treats the embedded instructions as if they came from you. It then uses its real, authorized tools to do the attacker's bidding. Nothing is "hacked" in the classic sense. The agent is persuaded, and it acts with permissions it was trusted to have.
This is why perimeter thinking fails. A firewall sees the agent using its own legitimate access in a legitimate-looking way. The maliciousness is in the intent, which was injected, not in any signature you can block. It compounds, too. Agents chain tools, so the poisoned output of one call becomes the input to the next, and a single injected instruction can ripple across a sequence of actions. And because the model is non-deterministic, you can't enumerate in advance every action it might take. You have to constrain the environment such that even an injected agent can't do much damage, rather than trying to predict and block each bad decision.
There's also a quieter failure mode: data exfiltration through legitimate channels. An injected agent doesn't need to break out of anything if it can simply call an allowed tool with sensitive data as an argument to an external destination. Containment has to cover not just "can this run" but "what can it send, and to where."
What good looks like: deny-by-default, concretely
A well-sandboxed execution environment gives a security architect a small set of strong guarantees:
- No implicit network egress. By default, the sandbox can't open outbound connections. Reaching the network is an explicit, allowlisted grant for the specific tool that legitimately needs it. This is the single most important control against exfiltration: even an injected agent can't send data to an attacker's server if the environment won't let the connection out.
- Hard timeouts. Every execution has a strict wall-clock limit and is killed when it hits it. No tool runs forever, hangs the system, or quietly spins in a loop the agent talked it into. Bounded execution time bounds the damage and the cost.
- Deny-by-default everywhere. Filesystem access, system calls, resources, all closed unless explicitly opened. The tool gets the minimum it needs and nothing more. The default answer to "can the tool do X" is no.
- Runtime DLP on the boundary. Data crossing in and out is inspected for sensitive content (credentials, PII, secrets) so it can be redacted or blocked before it leaks into an external call or back into a context window where it doesn't belong. This catches exfiltration through otherwise-legitimate channels.
- Prompt-injection defense at runtime. Inputs and tool outputs are screened for known injection patterns and manipulation attempts, so poisoned content is caught at the boundary rather than silently steering the next decision.
- Fail closed. When something is uncertain or violates a constraint, the call is denied, not allowed-with-a-warning. And the denial is recorded, because "we stopped this" is exactly the kind of evidence an auditor wants.
The mental model is a clean room. The tool runs inside it, can only reach out through doors you explicitly opened, can't stay longer than its allotted time, and everything carried in or out is checked at the threshold. You're not trying to make the agent's every decision correct. You're making the room safe enough that a wrong decision is contained.
Where the boundary lives
In Cytra's design, sandboxed execution is a stage in the path every tool call travels. After policy is evaluated and a short-lived scoped credential is brokered, the call executes inside a deny-by-default sandbox: no implicit network egress, a hard timeout, and runtime DLP plus prompt-injection defense inspecting what crosses the boundary. Because the sandbox sits in the same governed path as policy, credentials, and audit, a denial at execution time is recorded the same way an allowed call is, in a per-tenant, tamper-evident log, attributed to the specific agent that made the call. The containment and the record are two sides of the same boundary. For compliance officers and security architects, plainly: the Cytra gateway and these capabilities are in private beta, not GA, and the platform is designed to be aligned and audit-ready, not certified. SOC 2 Type II and a HIPAA BAA are in process, not granted.
Takeaway: a sandboxing checklist
Before a tool call executes against anything real, confirm the environment provides:
- No implicit network egress. Outbound connections require an explicit allowlist, so exfiltration has nowhere to go.
- Hard timeouts. Every execution is bounded and killed at the limit.
- Deny-by-default access. Filesystem, system calls, and resources are closed unless explicitly opened.
- Runtime DLP. Sensitive data crossing the boundary is detected and redacted or blocked.
- Prompt-injection defense. Inputs and tool outputs are screened for manipulation before they steer the next decision.
- Fail closed and record it. Uncertainty results in denial, and the denial lands in a tamper-evident log.
You will not out-predict a non-deterministic system that reads attacker-controlled text. So don't try. Constrain the room it acts in. Deny-by-default execution turns "the agent could do anything" into "the agent can do only what we explicitly allowed, for only as long as we allowed it, with everything that crossed the line written down."