In the last post we sealed the agent's computer in a room with exactly one door. This post is about the door, and about the one rule that makes it safe to open: the sandbox never holds a real credential.
The dangerous thing about an agent is not that it runs code. It is that it acts with your access. It reads the CRM as someone, queries the warehouse as someone, calls the internal API as someone. The whole game is to let it act with that access without ever putting the keys inside a box you have already decided to treat as hostile.
The sandbox holds one key, and it is almost worthless
At session start, the sandbox is minted exactly one credential: a per-task key, scoped to this agent, this workspace, and the specific actions granted for this task, and it expires with the session. That is the only secret inside the sandbox. It is not a CRM token, not a database password, not a model-provider key.
Scoped is the operative word. The key does not authorize the agent broadly. It authorizes exactly the connector tools the task was granted, at the severities the user approved, against the resources in scope. An agent given read access to one folder and the search tool on one connector gets a key that does precisely that and refuses the rest. The grant is decided before the session starts. The key is just its bearer token, minted fresh and thrown away when the work is done.
So picture an attacker who fully owns the sandbox and dumps every secret in it. What they get is one key that works only through our proxy, only for this task's narrow set of allowed actions, and only until the session ends. It is closer to a valet ticket than a car key. You can hand it over and lose very little.
The proxy does the real authentication
Every outbound call from the sandbox goes to one place: the proxy. The sandbox sends its request with the per-task key in the Authorization header. The proxy authenticates the key, checks policy, which is to say whether this agent is allowed this action on this resource at this severity, looks up the real upstream credential in its encrypted store, attaches it, and forwards the call.
The credential is attached server-side, on a machine the agent cannot reach, outside the sandbox entirely. The sandbox sends a request that means read this account. The upstream receives a request that means the invoking user, holding their own token, is reading this account. The agent expressed an intent. The proxy supplied the identity.
Three calls, three identities
The same shape covers cases that look very different from the outside.
For model inference, the sandbox sends the prompt and its task key. The proxy attaches the model-provider key and a user ID for cost attribution. The provider sees an authenticated call; the sandbox never sees the provider key.
For a read from a SaaS system like a CRM, the sandbox sends the request and its task key. The proxy attaches the invoking user's OAuth token, refreshing it if it has expired. The CRM sees an ordinary call from that user, carrying exactly that user's permissions and nothing more.
For an internal API, the sandbox sends the request and its task key. The proxy attaches a service-account credential or a customer-managed secret, along with a signed assertion of who the user is. The internal system authenticates against whatever scheme the customer already runs. Every time, the sandbox carries intent and the proxy carries identity.
Work through what a captured sandbox could do with its one key in each case. It can ask the proxy for actions inside the grant, which the proxy would have allowed anyway. It cannot ask for the provider key, the OAuth token, or the service-account secret, because the key does not name them and the proxy does not hand them out. The blast radius of a full compromise is the task's own authorized actions, and not one inch more.
The credentialed call runs in a trusted gateway
There is a second piece behind the proxy worth naming. Calls that need a real connector credential are executed by a hosted gateway that runs in the platform's trusted environment, not in the sandbox. The sandbox asks for a tool call. The gateway, which holds the credential, authenticates the request, applies authorization, and only then invokes the target system.
The agent runtime never receives the credential, not even for the instant of the call. It hands over an intent and gets back a result. The secret stays on the trusted side of the boundary for its entire life, from storage to use, which means there is no moment, however brief, when a compromised sandbox could read it in flight.
Context narrows access, it never widens it
Attaching the user's identity has a consequence worth being explicit about: the upstream system still enforces its own rules. When the proxy presents the invoking user's token to a CRM, the CRM applies that user's permissions, exactly as it would if the person clicked the button themselves. When it presents an authenticated role to a data warehouse, the warehouse still enforces what that role can see.
Context sits in front of these systems and can only narrow what the agent reaches, through grants, severities, and allowlists. It cannot widen it. An agent never sees more than the identity behind it is allowed to see, because the identity is real and the target checks it. The platform is a tighter gate on top of your existing access, never a way around it.
The credential never sits next to the code
Connector tokens, OAuth tokens, provider keys, customer-managed secrets: all of them live in the proxy's encrypted store. The sandbox cannot read them, cannot list them, and cannot find them by rummaging through its own memory, environment, and mounted files, because they were never put there. Contrast the usual pattern, where an application keeps its integration secrets in environment variables or a mounted file, one process compromise away from being exfiltrated in bulk. Here a total sandbox compromise yields a short-lived, narrow task key and not a single upstream secret.
This is also what makes prompt injection a contained problem rather than a catastrophic one. Suppose a document the agent reads tells it to exfiltrate the customer list. The agent has no upstream credential to do it with, no network path except the proxy, and a task key that does not authorize a bulk export. The malicious instruction reaches an agent that is simply not equipped to carry it out. The attack does not need to be detected to fail.
One door is also the place to put the controls
Because every external call funnels through one place, the proxy is where the controls live. Egress is gated by per-connector allowlists: a sandbox can reach the connectors its task needs and nothing else. TLS is enforced on every external call. DNS resolution happens at the proxy, not in the sandbox, so the sandbox cannot even name an arbitrary host to reach.
It is also a call you can see. Because identity is attached at a single point, the proxy knows which agent, which user, which task, and which resource sat behind every outbound request, which is the raw material for attribution and audit later. And because it is a single, well-defined chokepoint, the whole stream can be chained through the customer's own egress proxy or CASB. An organization that already inspects and logs outbound traffic keeps doing exactly that. One door is not just easier to defend. It is the only place where defending actually scales.
The secret an agent never holds
The previous post made the sandbox a sealed room. The proxy turns its one door into a one-way mirror: the agent can act on the world through it, and it can never grab what it would need to act on the world on its own. The most reliable way to keep a secret out of an attacker's hands is to make sure it was never within reach. The sandbox never holds the credential, so there is nothing there to take.
It is a small idea with a large consequence. The most sensitive thing in the system, your access to your own data, is the one thing the agent never has to be trusted with.