Good walkthrough. Moving credential custody out of the agent process is the change I've wanted to see as a default, because right now "don't leak the key" depends on the model behaving, which is not a control.
One question from reading the providers section: once the supervisor injects the resolved credential into the sandbox, does the agent process still see it in its own environment, or is it attached at the egress proxy so the agent never holds the raw value? Those are very different threat models. In the first case a prompt-injected agent can still read and send the token to any allowed destination; in the second it can only use it through the policy.
Also worth being clear for readers: the Z3 check proves a policy is consistent with the rules you wrote, not that the rules match your intent. Still a big step up from YAML nobody reviews.
Senior Lead Tech/Dev, 20+ years. Building NoireBox — the flight recorder for your of AI agents. Proof, not promises. Rust · TS · Python · PHP. I write about trust in AI.
Answered from the source, since it's open: the agent process sees the credential in its own environment. inject_env in crates/openshell-providers merges the resolved provider environment into the child process's env map, and the README is explicit that the sandbox supervisor "injects credentials into agent child processes." So your first threat model is the live one: a prompt-injected agent can read the token out of its own environment and send it to any destination egress policy allows. Your second half exists as a surface, not a default — there is an openshell-gateway-interceptors crate for middleware on the request path, so raw-value-stays-gateway-side is buildable in principle, but nothing in the default path attaches at egress today.
The Z3 point is the sharper of the two. Consistency is cheap, intent is unprovable: a prover answers "does this policy contradict itself," never "is this policy what you meant." Which is why the human approval step is load-bearing rather than ceremonial — and why, on our side, the receipt binds the policy's hash: it proves the policy checked is the policy on record, not that the policy is wise.
Thanks for going to the source, that settles it. If inject_env puts the resolved credential in the child's environment, then a prompt-injected agent can read it and send it anywhere egress allows. The protection comes from the egress policy, not from custody. Good to know the interceptors crate exists, though. Keeping the raw value on the gateway side looks like the design worth pushing for upstream.
Agreed on Z3 too. Binding the policy hash into the receipt is a nice touch: it proves which policy was checked, and leaves "is this the right policy" to the human approval step.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Good walkthrough. Moving credential custody out of the agent process is the change I've wanted to see as a default, because right now "don't leak the key" depends on the model behaving, which is not a control.
One question from reading the providers section: once the supervisor injects the resolved credential into the sandbox, does the agent process still see it in its own environment, or is it attached at the egress proxy so the agent never holds the raw value? Those are very different threat models. In the first case a prompt-injected agent can still read and send the token to any allowed destination; in the second it can only use it through the policy.
Also worth being clear for readers: the Z3 check proves a policy is consistent with the rules you wrote, not that the rules match your intent. Still a big step up from YAML nobody reviews.
Answered from the source, since it's open: the agent process sees the credential in its own environment.
inject_envincrates/openshell-providersmerges the resolved provider environment into the child process's env map, and the README is explicit that the sandbox supervisor "injects credentials into agent child processes." So your first threat model is the live one: a prompt-injected agent can read the token out of its own environment and send it to any destination egress policy allows. Your second half exists as a surface, not a default — there is anopenshell-gateway-interceptorscrate for middleware on the request path, so raw-value-stays-gateway-side is buildable in principle, but nothing in the default path attaches at egress today.The Z3 point is the sharper of the two. Consistency is cheap, intent is unprovable: a prover answers "does this policy contradict itself," never "is this policy what you meant." Which is why the human approval step is load-bearing rather than ceremonial — and why, on our side, the receipt binds the policy's hash: it proves the policy checked is the policy on record, not that the policy is wise.
Thanks for going to the source, that settles it. If inject_env puts the resolved credential in the child's environment, then a prompt-injected agent can read it and send it anywhere egress allows. The protection comes from the egress policy, not from custody. Good to know the interceptors crate exists, though. Keeping the raw value on the gateway side looks like the design worth pushing for upstream.
Agreed on Z3 too. Binding the policy hash into the receipt is a nice touch: it proves which policy was checked, and leaves "is this the right policy" to the human approval step.