Capability · Secrets
A write-only vault the model can never read
A write-only vault: the agent references {{secret:NAME}}, the plaintext is substituted only at dispatch, and the model never sees the value.
Giving an AI agent your API keys is the part everyone rightly hesitates over. monopea removes the dilemma with a write-only vault: you PUT a secret once, and from that moment there is no API, no tool, and no prompt that returns the plaintext — not to you, and not to the model.
The agent still gets to use the credential. It just never gets to see it. Plans and tool calls carry the reference {{secret:NAME}}; the real value enters the pipeline only at the moment of dispatch, outside the model’s context, and is scrubbed from anything that flows back.
How a write-only secrets vault works
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
{{secret:NAME}}: the model plans with references, not values
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.
Substituted at dispatch, scrubbed on return
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.
Encrypted per tenant, stored in Zurich
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.
Why it matters
The model never sees the value
Credentials exist in the model’s world only as {{secret:NAME}} references. There is nothing in context to leak.
No read-back, by construction
The API returns name, description, and last-four only. Exfiltration would require a path that does not exist.
Scrubbed on the way back
Tool results are cleaned of secret echoes before they re-enter the agent’s context.
Swiss at rest
Envelope-encrypted, tenant-bound, and stored in Zurich with the rest of your data.
FAQ
Secrets vault, in short
- Can the AI read my secrets?
- No. The model only ever sees the {{secret:NAME}} placeholder. The plaintext is substituted into the tool call at dispatch, in the runtime, outside the model’s context — and tool results are scrubbed of echoes before they return.
- Can I read a secret back after storing it?
- No — the vault is write-only for everyone, including you. GET returns the name, description, and last four characters so you can verify which key is stored. To change a value, PUT it again; to remove it, DELETE it.
- What if a tool echoes the secret back in its response?
- Responses are scrubbed before they re-enter the agent’s context. An API that reflects your credential in its output does not put it in front of the model.
- How are secrets stored?
- Envelope-encrypted at rest, with the encryption bound to your tenant via AAD so values cannot cross tenant boundaries — and stored in Zurich, Switzerland.
Keep exploring
Approval gate
Default-deny control: mutation-capable tool calls become pending proposals and wait for your decision before anything is dispatched.
Swiss residency & routing
Persistent data stored in Zurich, Switzerland; processing on EU infrastructure; and a Swiss model track that keeps inference in Switzerland when you choose it.
MCP tool catalog
Connect any MCP-compatible tool — and every one of them onboards default-deny, with credentials from the write-only vault.