How it stays secret
The core promise is narrow and precise: your AI agents and your developers’ machines can use a secret without ever seeing its value. The agent makes an authenticated API call, queries a production database, or signs with an SSH key — and the plaintext is injected at the network edge, never handed back.
This page is written for the skeptical senior engineer. It lays out exactly what Veil Keys defends against, the mechanism behind each guarantee, and — just as important — the things it does not claim. If a security model overclaims, it can’t be trusted, so the limits are stated as plainly as the wins.
The threat model
Veil Keys exists because the dangerous moment for a secret is the moment a human or an agent can
read it. Once a value is readable, it leaks — into a model’s context window, a log line, a .env
file, a screenshot, a pasted snippet. Each row below is a way secrets escape today, and the control
that closes it.
| Threat | What goes wrong without Veil | The control |
|---|---|---|
| Secret in an AI context window | The agent is handed the raw key; it now lives in prompt history, the model provider’s logs, and any tool the agent calls. | The agent gets the use permission, never reveal. It triggers calls; the value is injected at the edge and never returned. |
| Secret in logs | A key printed once during debugging persists in log storage forever. | Secrets are never written to logs — not request logs, not the audit trail, not error traces. |
Secret in a .env on disk | A plaintext file on every developer and CI machine; one stolen laptop or leaked artifact exposes everything. | The value never lands on the machine. CI resolves secrets into the build’s process memory at run time; agents never receive them at all. |
| Over-broad reach | One leaked key can hit any host, any database, any method. | Domain binding pins a credential to one upstream host; agent tokens narrow access to specific tools and workspaces and can never exceed their creator. |
| Stolen database dump | An attacker who exfiltrates the database reads every secret. | Everything sensitive is stored as ciphertext under envelope encryption; a raw dump is useless without the key-wrapping hierarchy. |
| Compromised agent | A subverted agent reads and exfiltrates the secrets it was given. | A use-only agent has no path to plaintext. Even fully compromised, it cannot read a single secret value. |
| Exfiltration by redirection | An attacker with edit rights points a “filled” secret at a host they control. | Repointing where a secret is sent requires reveal, not write — redirection is treated as a read and blocked. |
The guarantees
These are the things the system is built to hold, each tied to a mechanism documented in this section.
The honest limits
A hosted broker buys convenience — no infrastructure to run, sync across machines, instant onboarding — and the tradeoff is that you trust the hosting. State it plainly:
What that means concretely, and what else to weigh:
- You trust the hosted infrastructure. Encryption at rest defends against a stolen dump and defends each workspace key independently — but it does not remove your trust in the operator at injection time. A fully local, zero-knowledge mode (where the broker runs on your own device and the server only stores ciphertext it can never unwrap) is on the roadmap as the stronger option for teams that need it.
- Domain binding is per-host, not per-route by default. A credential bound to
api.stripe.comis refused against any other host, but it permits any path on that host unless you add finer policy. Bind narrowly and scope tokens to the specific tools they need. - The broker is only as good as its registration. If you bind a secret to the wrong host, it will faithfully serve that host. Domain binding enforces what you declared, not what you intended.
- A compromised account with
revealcan reveal. The model protects against compromised agents (which holduse) and database dumps. It does not make a stolen owner session harmless — which is why reveals are rate-limited, 2FA is org-enforceable, and a password reset kills every session.
Where to go next
- Encryption at rest & in transit — the cipher suite and key hierarchy.
- Domain binding — how a secret is refused against any other host.
- Access control — roles, per-workspace grants, 2FA, and use-vs-reveal.
- The audit trail — answering “what did this agent touch, and when.”
- Reliability & data handling — availability, backups, and deletion.
For the wider picture of how agents call APIs without reading keys, see the agent broker and database proxy.