Sandbox, capability and identity: task-based security in agentic systems

Two agents work on different branches. Neither overwrites the other's file. The team concludes that the execution is isolated.

But they can both still use the same credential, query the same database, call the same tool and reach the same network. File separation resolved a work collision; did not resolve the security border.

In agentic systems, security needs to accompany the entire task: who executes, in what environment, with what capabilities, on what data, for how long and under what authority.

Executive summary

A worktree protects concurrency in the repository. A sandbox limits execution. Identity attributes actions. Capabilities restrict what each identity can do. Policy decides when the combination is valid.

No layer replaces the others. Task security arises from the intersection between them.

Worktree is not sandbox

Worktrees are excellent for isolating competing changes. Each session receives its own working tree, branch and history. This reduces collisions and makes review easier.

The operating system, however, does not interpret a branch as a permission boundary. A process can continue reading external paths, variables, keychains, sockets, or network services if the environment allows it.

The correct contract is:

worktree = isolamento de mudança
sandbox  = isolamento de execução
policy   = isolamento de autoridade

Public code agent documentation describes sandbox, workspace access, and networking as distinct controls. FORGE uses this separation as a design principle; the existence of a specific sandbox does not certify the product that adopts it. [R2-C3]

Identity needs to come to action

“The agent did” is an operationally weak sentence. Which agent? In whose name? In which session? With what paper? Which version of workflow granted the permission?

A useful identity should allow you to call:

1. person or system that initiated the task;
2. session that received the objective;
3. role or specialty assumed;
4. grant effective;
5. action performed;
6. artifact or effect produced;
7. review or acceptance decision.

This does not require exposing internal reasoning. Requires recording sufficient operational facts to assign, investigate and revoke.

Capability is more accurate than “access”

Allowing “GitHub” says little. A task may need to read an issue, create a branch and open a PR, without being able to change secrets, protection rules or releases.

Model grants as verbs about resources:

issue:read
branch:create
repository:write@worktree
pull_request:create
secret:read = denied
release:publish = denied

The same goes for banking, CRM, files and infrastructure. capability must be minimal, task-bound, and revocable. Models and adapters can suggest operations; enforcement needs to be outside the text that executor itself controls. Public sources show different implementations of agents, workspaces and permissions, not a universal authorization standard. [HARNESS31-C4]

A five-dimensional matrix

Before starting an execution with a material effect, answer:

The grant should not outlive the reason it was created. A completed session does not need to maintain write access; a preview does not need a production credential; a reviewer does not need to run the code he reviews.

Network is part of the contract

Agents that browse, install dependencies or consult external services expand the surface of prompt injection, exfiltration and supply chain.

Three policies are more useful than the “internet on” binary:

• deny: no exit; dependencies and data enter through approved artifacts;
• allowlist: only required destinations and methods;
• escalate: new domain requires decision before the first call.

It is also important to control feedback: downloading a package, sending content, creating a transaction and publishing a comment are different effects.

Secrets do not belong to prompt

A credential inserted in context may reappear in a transcript, tool call, error or artifact. The model does not need to know the secret to using a capability.

Prefer:

• broker or vault that exchanges identity for a short token;
• minimum scope and explicit environment;
• injection only in the authorized process;
• logs with masked value;
• observable revocation;
• negative test that proves access denied outside of the task.

The expected result is not “the agent promised not to show”. It is “the architecture did not deliver the value to the context and the effect outside of grant failed”.

Task security in practice

Consider an agent tasked with correcting public documentation:

1. receives a public issue and an exclusive worktree;
2. reads only the allowlisted repository and sources;
3. does not receive deployment secrets;
4. can edit scope files and run local validators;
5. can open PR, but not approve it or publish release;
6. CI uses separate identity to verify;
7. the deploy uses another identity, after the merge;
8. all grants in the session expire on close.

Separating identities reduces circular authority. It also makes incidents more localizable: a failure of research, implementation, review, or publication leaves evidence on a different plane.

The most important test is negative

Declared configuration is not enough. Check that:

• the agent does not read files outside of workspace;
• network to unauthorized destination fails;
• development token does not reach production;
• reviewer does not write to asset;
• grant expired stops working;
• one session does not access memory or data from another;
• logs identify subject, resource and decision without leaking sensitive content.

An architecture can appear constrained and still carry a bypass. The negative test turns the boundary into an observable property.

What this article proves — and what it doesn't prove

Eligible sources maintain that sandbox, network, identity, and authorization are separate controls and that the exact profile depends on the environment. They do not demonstrate that a specific tool is safe in any setting, nor that isolation eliminates prompt injection, human error, or supply chain risk.

This article proposes a task-based security contract. Threat model, testing and operation remain specific to each product.

Conclusion

An agent should not be given “system access”. It should receive a small capacity, in a limited environment, for a short time, linked to an identity and evidence.

Worktree organizes competition. Sandbox reduces range. Identity assigns. Capability limits. Policy decides. Security appears when all these layers agree on the same task.

Previous reading: Graph, loop or hybrid?. Next suggested reading: Taste, responsibility and clarity.