An agent’s task may be narrow. Its access shouldn’t be unlimited.
Introducing the thinking behind Veto Sandbox: why execution boundaries matter, how they complement authorization and what we’re building next. https://x.com/i/article/2115492155657469952
When AI Agents Execute Code, the Environment Becomes a Security Boundary
Introducing Veto Sandbox, a new product in development under Veto Protocol.
An AI agent investigating a software issue clones a repository, reads its instructions, installs dependencies and runs a test command.
That sequence looks routine. It is also a sequence of trust decisions.
The repository may contain instructions intended to manipulate the agent. A dependency may execute malicious installation code. A command presented as a diagnostic step may attempt to read credentials, contact an external server or modify files outside the project.
If the agent has broad access to the host machine, the consequences can extend well beyond the task it was asked to complete.
As agents move from suggesting actions to executing them, their operating environment becomes part of the security model. What matters is not only whether an agent understands a task but what the code it runs can reach when something goes wrong.
That is the problem behind Veto Sandbox.
Useful capabilities create real exposure
The capabilities that make agents useful also create opportunities for misuse.
Shell access allows an agent to compile software and run tests. It can also allow destructive commands. Package installation supplies useful libraries but can execute untrusted third-party code. Network access enables research and integrations while creating a potential path for data exfiltration.
An attacker does not necessarily need to compromise the model itself. They may try to influence material it encounters: repository instructions, downloaded files, tool responses or documentation containing commands.
A successful manipulation could cause an agent to invoke a tool in a way the user never authorized. Separately, a malicious dependency can act through its own code, regardless of the agent’s intentions.
The exposure depends on the environment. Credentials available to a process may be read. Writable files may be altered. Reachable services may be contacted. Available compute may be consumed by unauthorized workloads.
Not every failure is an attack. Mistakes and ambiguous instructions can produce damaging actions too. The common issue is execution authority that extends beyond the task’s requirements.
Introducing Veto Sandbox
Veto Sandbox is a new product in development under Veto Protocol. We are designing isolated, on-demand cloud environments where applications can execute agent-initiated code, process files and produce results within defined limits.
Our initial focus is developers whose agents execute generated or third-party code as part of an application. They need a practical way to run those workloads without automatically exposing their everyday machine, unrelated projects or production infrastructure.
The intended experience is straightforward: create an environment, provide the task inputs, execute the workload, retrieve the results and end the session.
The core product is the execution environment, not a new AI model. We will confirm supported agent-hosting and integration patterns with the initial release scope.
Our design priorities include workload isolation, file boundaries, resource limits, execution lifetimes and network restrictions. These are development objectives, not claims of completed functionality. We will publish the chosen implementation, tested behavior and known limitations as the product progresses.
A workspace for an unfamiliar repository
Consider an agent asked to investigate a failing test and generate a proposed patch.
It needs the repository, a compatible runtime and the dependencies required to reproduce the issue. It does not automatically need the developer’s SSH keys, cloud credentials, other repositories or access to production services.
In the workflow we are designing, the project would be supplied to a separate task environment. The workload would receive defined inputs, resource limits and explicitly configured connections.
The application could retrieve test results and a proposed patch without granting the workload permission to deploy that patch. Additional access would need a separate, deliberate decision rather than being inherited from the host.
This would not make the repository trustworthy. It would provide a more controlled place to inspect and execute it.
The distinction matters: unfamiliar code should not inherit broad access simply because an agent needs to run it.
Containment not a promise to detect every attack
We are not positioning Veto Sandbox as a system that recognizes every malicious instruction or prevents every harmful action.
Detection and containment serve different purposes. A detector attempts to identify suspicious behavior. An execution boundary limits what a workload can do, including when a detector misses something or no detection is involved.
A malicious process may still execute inside a sandbox. The important question is what it can access from there.
A workload with unrestricted outbound access may transmit sensitive files it was legitimately given. An environment containing powerful credentials may enable unauthorized activity. A poorly configured host can undermine separation between workloads.
Execution isolation also does not establish confidentiality from the infrastructure operator. That is a separate trust boundary and our documentation will need to identify the systems and parties the platform relies on.
“Sandboxed” should describe an architecture not substitute for explaining its limits.
How this connects to Veto Protocol
Veto Protocol’s existing focus is authorization: identifying agents, defining permitted access, requiring human approval where appropriate and recording decisions for supported requests passing through its gateway.
Veto Sandbox addresses the environment in which code executes.
Authorization asks whether an agent may retrieve a resource or request an action. Isolation determines what an executing workload can reach and use.
These layers can complement each other. A task might be authorized to read a repository and generate a patch while remaining unable to access unrelated accounts or publish changes without a separate decision.
Our direction is to connect agent identity, resource permissions, bounded execution and activity records into a coherent developer workflow. That integration remains part of the development plan, not a completed capability.
Veto cannot govern independent connections outside its enforcement path.
The boundaries we are prioritizing.
Workload separation is the foundation. The environment needs a defined boundary from other customers’ workloads, the host and the platform’s management services. Authentication, infrastructure configuration, patching and incident response all contribute to maintaining it.
Resource controls are equally important. A workload can consume excessive CPU, exhaust memory, fill storage or produce unbounded output. Execution deadlines and relevant quotas need to be enforced independently of the agent.
The workload should not be able to increase its own limits, modify network policies or obtain the credentials used to administer the platform.
Network restrictions must account for more than whether internet access is enabled. Internal addresses, cloud metadata services, redirects and destination resolution require consideration. Access to a dependency repository should not silently become permission to contact any endpoint.
File handling should make inputs and outputs deliberate. Credentials should not be supplied as ordinary task data. Generated patches, executables and documents should remain untrusted when they leave the environment; exporting an artifact does not certify it as safe.
Execution records can help developers investigate failures, but logs may contain sensitive information. Access, redaction and retention need their own controls.
We intend to test these boundaries with failure scenarios and adversarial workloads not only demonstrations in which an agent follows instructions correctly.
A temporary environment still has consequences
Requesting termination is not the same as confirming that execution has stopped. The platform needs to handle failed or delayed shutdowns and report their status accurately.
Stopping a runtime does not automatically cancel external jobs, revoke credentials issued during the task or undo completed actions. Information already transmitted cannot be recalled.
Deletion is a separate concern. Workspace files, execution logs, snapshots and backups may have different retention requirements. Those policies must be explicit.
Likewise, an isolated runtime does not make external model inference private. If task content is sent to a model provider, developers need to understand that separate data flow.
These limitations belong in the product documentation and user experience, not in fine print after deployment.
Why we are building this
We started Veto around a practical question: what should an agent be allowed to do?
Veto Sandbox extends that work with another: where should potentially untrusted code run, and what should remain beyond its reach?
Our aim is to give developers a usable execution environment with boundaries they can understand, configure and test. That requires careful engineering and evidence not claims that autonomy has become risk-free.
If your application executes generated or third-party code, we’d like to understand your workflow and what you would need from an early sandbox pilot. Real tasks, operational constraints and failure cases will help shape the first release.
Agents need the ability to act. Their execution environments should not give them unlimited reach.