Add a credential

A credential is a secret you hand to Veil Keys once. You paste it into the app, it’s encrypted, and from then on your agents and CI can use it without ever seeing its value. This page covers every kind of secret you can store and exactly how to add each one.

The basic flow

Every credential is added the same way in the app:

1. Open app.veilkeys.com and select the workspace the credential belongs to.
2. Click Add credential.
3. Choose a service from the catalog — Stripe, OpenAI, GitHub, AWS, and more — or pick Custom to define your own.
4. Set the auth scheme and base URL (the catalog pre-fills these for known services).
5. Paste the secret value and save.

The status shows ready once it’s stored. The value is encrypted at rest under the workspace’s own key and is never displayed again — the only path back to plaintext is an explicit reveal permission.

Let an agent pre-register the service

You don’t have to start in the UI. An agent with create_service permission can register a service first — its name, base URL, and auth scheme — and leave the secret blank. You then open the app, see the pending service, and fill in the secret value. The credential is ready only once you’ve supplied it. This keeps the workflow simple (the agent describes what it needs) while keeping the secret strictly in your hands.

Secret kinds

Veil Keys supports five kinds of secret. Each is attached to outbound requests differently, but all share the same guarantee: an agent uses them, never reads them.

1. Static API key or token

The most common case: a long-lived key or bearer token. Choose how it’s attached:

• Bearer — sent as Authorization: Bearer <value>.
• x-api-key (or another custom header) — sent as a header you name.

Set the base URL (e.g. https://api.openai.com) and paste the key. Done.

2. AWS (SigV4)

Store an AWS access key ID and secret access key. Veil signs each outbound request with SigV4 at call time, so the agent can hit AWS service endpoints without ever holding your AWS credentials. Bind the credential to the AWS endpoint you intend to call.

3. OAuth2

For services that use OAuth2, you store three things: the client ID, the client secret, and a refresh token. Veil Keys handles the rest — it automatically refreshes the access token when it expires and injects a valid token into each request. You never paste short-lived access tokens, and your agent never sees any of them.

4. Database (Postgres)

Paste a Postgres connection string / DSN (for example postgres://user:pass@host:5432/db). This powers the query_db tool: agents can run read-only queries through the database proxy, which blocks destructive statements and masks PII before any row reaches the agent. The agent never receives the connection string itself.

The database proxy is available on Pro and Team plans. See The database proxy for what it allows and how masking works.

5. SSH keys

Store an SSH private key (ed25519 today) and Veil acts as an SSH agent that brokers signing. The private key never leaves Veil — the local veil ssh-agent asks Veil to sign authentication challenges, so git push and ssh work normally while the key stays sealed.

See SSH brokering for the full setup.

Permissions on a credential

Access is granted per workspace, and an agent or teammate gets one or more of these:

Most agents need only use. Grant reveal deliberately — it’s the one permission that can expose plaintext, and it’s what veil run (CI injection) requires.

Next steps

• Quickstart — connect an agent and make your first brokered call.
• Tokens — turn permissions into scoped, revocable tokens.
• The agent broker, database proxy, CI injection, and SSH brokering.