A write-only vault the model can never read

You store a secret with a single write: PUT the name and value, and the vault envelope-encrypts it at rest. Reading it back is not a permission you can grant — the API simply has no path that returns plaintext. GET returns the name, description, and last four characters, nothing more.

That asymmetry is the security model. Rotation is another PUT; removal is a DELETE; verification is the last-four. Because no read path exists, a compromised session, an over-curious prompt, or a misbehaving model cannot exfiltrate what the interface cannot express.

• PUT is the only way in; no API path returns plaintext
• GET returns name, description, and last four characters only
• Rotate by writing again; remove with a DELETE

Inside the agent’s context, a credential is only ever the placeholder {{secret:NAME}}. The model drafts tool calls around that reference — it can reason about which secret a call needs without ever holding the value. A prompt-injection attempt cannot leak what was never in the context window to begin with.

You can see this on any pending proposal: the arguments show the placeholder, unexpanded. What you approve is the call with the reference; what dispatches is the call with the value.

Plaintext substitution happens at exactly one point: dispatch, after approval, in the runtime — never in the model’s context. And on the way back, tool results are scrubbed for echoes of the secret before they re-enter the conversation, so a service that reflects your key in a response does not hand it to the model.

The window in which plaintext exists is the tool call itself — the same window it would occupy if you made the call by hand. Before and after, the model’s world contains only the reference.

At rest, every secret is envelope-encrypted and bound to your tenant with authenticated additional data (AAD), so a ciphertext cannot be replayed into another tenant’s context. The encrypted values live with the rest of your persistent data in Zurich, Switzerland.

Combined with the approval gate, this closes the loop: the model plans with references, you approve the call, the runtime injects the value, and the audit trail records that it happened — without the value ever appearing in it.