Credentials and the secret policy

An agent does plenty of work that needs a credential: a token to clone a repository, a key to call a model, the secret a connected tool authenticates with. The question a security team asks is the obvious one, and it is the one this page answers: where do our keys live, who can read them, and what stops an agent from walking off with one?

The short answer is built from three guarantees. Your secrets live in a vault that is set but never read back, by anyone. You cannot configure a sandbox to carry your managed keys as standing environment variables: the platform refuses them at the boundary, on every host. And the credentials a run actually needs are resolved at the moment of use and handed to the single command that needs them, then cleaned up, never left sitting in the container for an agent to harvest. Taken together, the agent works with the access these grant, never with a standing key it could print, copy, or leave behind. This page is the policy that makes those guarantees concrete. It is the deep version of the secrets page, which is where you set the keys, and the full statement of the second pillar in the security overview: the agent never holds your keys.

The agent never holds your keys

Start with where a key lives. Each workspace has its own secret vault, and a value you put in it is set but never read back, not by you, not by an administrator, and not by an agent. There is no reveal button, no copy action, no read path for the plaintext. The platform keeps the value and gives it back to no one.

So when a run needs to do something a credential unlocks, it does not get a standing copy of the key to keep. The platform resolves the value on the server at the moment it is needed and hands it to the one command that needs it, scoped to that operation, then takes it back. The vault value itself never leaves the server, and nothing is written to the container's standing environment for later commands to inherit. The agent gets the use of a credential for the moment it needs it, narrowed to the operation in front of it, never a key it can carry through the rest of the run.

That single decision, that a credential is resolved at the moment of use and scoped to the operation, is what the rest of this page makes concrete: where in a run a credential might be needed, the narrow channels one can travel, and the boundary that refuses a managed key configured to enter any other way.

A policy for every phase of a run

A run is not one moment; it passes through several phases, and a key could in principle be wanted at any of them. So instead of one blanket setting you would have to trust covers every case, the policy answers the question separately at each phase, and the answer for your managed keys is the same one every time: no, not as a standing environment variable. The table below is that answer, phase by phase, so you can check it rather than take it on faith.

Read down the table and the shape is plain. Your managed keys, the model-provider keys, the Git tokens, the integration secrets, are forbidden from a sandbox's standing environment at every phase. The only credentials that move during an agent turn are short-lived leases resolved at the moment of use and scoped to a single operation, and the only secrets used at the sidecar-internal phase are the platform's own control-plane keys, which the agent never inherits. There is no phase where a long-lived key of yours is left standing in the sandbox's environment for a later command to read.

The narrow channels a credential can travel

When a credential does have to reach a run, for one operation under a lease, the platform's goal is the same every time: get it to the one command that needs it and nowhere else, so it never becomes a value the whole container can read. To do that it picks the tightest of a fixed set of channels, each one a different way to hand a credential to exactly one command and no more.

• Refused. The default for anything that does not have an explicit reason to enter. A forbidden credential does not travel at all.
• One process's environment. Not the container's environment, where everything could read it, but the environment of a single spawned command, which sees it and exits. The value never becomes ambient.
• A temporary file. Written to a path readable only by that run, with restrictive permissions, then deleted when the command finishes.
• Standard input. Streamed into one command's input and gone when the command ends, never written down at all.
• A git credential helper. For Git operations, a small helper hands the token to git at the moment it asks and to nothing else.
• A package-manager config. For a dependency install, a scoped config file the installer reads, then removed.

The thing these have in common is the thing that matters: a credential reaches the smallest possible audience for the shortest possible time. It is never set as a container-wide environment variable that every later command would inherit, because that is the one channel from which a key spreads. The platform writes the credential to a single command's patch at the moment of use and cleans it up after, never to the sandbox's standing environment.

Forbidden by default, and enforced at the door

A policy is only as good as its enforcement, so the forbidden rule is not a guideline the platform hopes holds. It is checked at the boundary where a sandbox is launched, before the sandbox's environment is handed to the host. If the request to start a sandbox carries one of your managed keys as an environment variable, the platform refuses to start the sandbox at all, and names the offending key so the mistake is obvious.

This is the guarantee that holds today, on every host, with a test that fails the build if any code path tries to bypass it. Even a misconfigured profile that tried to pass a model key or a Git token into the sandbox's environment is caught at the door and turned away, whether the sandbox runs on the managed pool, your own Kubernetes, or a local Docker engine. You cannot stand up a sandbox with your managed keys sitting in its environment for an agent to read, because the one path that would let you is closed at the boundary and checked on every launch.

A key you bring is held the same way

Bringing your own model-provider key changes nothing about this. A key you supply lands in the same vault under the same name as a key the platform manages, and it inherits the same treatment: held on the server, never returned, refused from a sandbox's standing environment at the boundary. There is no second-class path where a key you brought is handled more loosely than one the platform provides.

It helps to separate the kinds of credential a run touches, because they reach it differently. A Git push or a tool call is an action the agent runs as a command, so the credential is leased to that one command for that one operation, resolved at the moment of use and gone after. A model call is different: the runtime that talks to the provider needs the model-provider key to make the call, so the platform resolves that key on the server for the run's own model runtime, scoped to the run and never written to its disk or baked into its image. And the platform's own gateway uses control-plane secrets of its own during a run, the keys that sign the sidecar's bearer and reach the platform's message channel; those are the platform's, not yours, and the agent never inherits them. In every case the value comes from the vault or the control plane at run time rather than from a standing secret you placed in the container, and the key behind your work is one you set once and the platform resolves when the work needs it, not a value you paste where it could be read back.

What this looks like for one key

Walk a single key through its life and the policy stops being abstract. Priya sets the team's model-provider key once, in the secrets console: she pastes the value, saves, and the field goes back to showing only that the key is set and who set it. She cannot read it back, and neither can anyone else. Weeks later, an agent run on the Insights project needs to call the model; the platform resolves that key on the server for the run's own model runtime, scoped to that run, and the agent does its work without the value ever becoming a standing secret it could print, copy, or leave behind. When the team rotates the key, Priya writes the new value over the old one in the same field, and the next run resolves the new key. Between the moment she set it and the moment she replaced it, the key was used many times and read back zero.

Rotating a key is one write

Because a value is only ever set and never read back, rotating a credential is the same action as setting it the first time: you write the new value over the old one in the vault. There is no separate rotation flow to learn, no old value to revoke by hand, and no list of places the key was copied to that you have to go and update, because it was never copied anywhere standing. The platform held one value, and now it holds the next one.

What happens to work already running is the quiet benefit of resolving credentials at the moment of use. A run finishes the operation it is in the middle of on the value that was current when that operation started; the next operation, the next lease, the next model call, resolves the new value. So a rotation does not have to interrupt work in flight or be timed around a coordinated stop. You replace the value, and runs pick it up at their next moment of use. For a key you suspect is compromised, this is the property that matters: one write, and from there every new operation across every host resolves the new credential, with no standing copy of the old one cached in a sandbox to keep using it.

Nothing leaks through the seams

The last place a secret could escape is the exhaust of a run: a log line, a transcript, an event. The platform redacts there too. A credential value that appears in a command's output, a stored transcript, or an emitted event is replaced before it is written, so a key cannot slip out through the record of the work. The name of a secret stays visible, because naming a key is useful for understanding what happened; the value does not, because a value is the thing that must never be read back. The same write-only rule that governs the vault governs the trail.

Why the secret policy works this way

The decision under all of it is that a credential that is never left standing in the sandbox is a credential there is nothing to harvest. A key that is not sitting in the sandbox's environment between operations cannot be printed by a later command, cannot be exfiltrated through a clever prompt that comes after the work, cannot be read off a disposed disk, and cannot be reused for something it was not granted for, because it was never parked in the place those attacks reach. The value comes from the vault at the moment the work needs it, scoped to the operation, and the vault gives it back to no one. The work the agent does is real, the access it acts with is real, and yet there is no standing key behind it to walk off with, which is the property that makes giving an agent real credentials defensible in the first place.

Naming the phases and fixing the channels is what turns that decision into something a reviewer can check rather than trust. The rule is not "we are careful with secrets." It is "a managed key cannot be a standing environment variable in a sandbox, enforced at the boundary on every launch, and a credential that must be used is resolved at the moment of use, travels the narrowest channel for the shortest time, then is cleaned up." Every clause of that sentence resolves to a mechanism, and the mechanisms are the same on every host. The agent is powerful inside its container; your standing keys are not in there with it.

For the person who owns security, this is the answer to "where do our keys live and who can read them." They live in a per-workspace vault, are never returned to anyone, and cannot be configured as standing environment variables in a sandbox, a check enforced at the boundary on every launch. The credentials a run uses are resolved at the moment of use and scoped to the operation, so a key the agent could talk a later command into printing is a key that was never left there to print.

For an engineer, the practical version is that you reference a credential by name and never paste it where an agent could see it. The platform resolves it at the moment of use and hands the run only what it needs for the operation in front of it. Rotating a key is replacing one value in one place; nothing else changes.

For an administrator, the policy is the rule behind the secrets console you manage. You set the workspace's keys once; the platform decides, per phase and per channel, exactly how each one may be used, and refuses anything that tries to reach the agent another way.

For a prospect evaluating the platform, this is the mechanism, not a posture statement. The claim "the agent never holds the keys" is not a slogan; it is a forbidden set enforced at the boundary, a fixed list of narrow delivery channels, and redaction at every seam, each of which you can check.