How to give an AI agent production credentials without the agent seeing them

The safest setup is one where the agent never holds the production credential at all. It asks for one specific operation, and something it cannot read performs that operation with the key. Lit's Agent Keychain works this way. You encrypt the credential in your browser to a key that only exists inside a Lit hardware enclave. You approve a specific agent to use it. When the agent calls a connected service, such as reading a Stripe balance or a file from GitHub, Lit decrypts the credential inside the enclave, makes that one call, and returns only the result. Only the person who adds the credential sees the value. The agent and the Keychain operator never receive it, as long as the web app and Lit's enclave code are honest.

I will explain why the usual approaches leak, how this one works, and what it does not protect against.

Why the usual approaches leak

Most teams start by putting the key in the agent's environment, or by pulling it from a secrets manager at runtime. Both keep the key out of the repository, which is good. But once the agent has the key, it can show up anywhere the agent writes. Its prompts, tool outputs, and transcripts get logged, sent to a model provider, saved by the agent framework, and sometimes pasted into tickets. Anyone with access to those logs then has your production key. So does anyone who can make the agent print its environment through a prompt injection.

A credential broker that adds the key to outgoing requests is better, because the agent never sees the value. The question then is who can see inside the broker. If it is a service your vendor runs, the vendor's staff can.

How it works on Lit

Each secret in Agent Keychain gets its own Lit Action, a small program whose identity is a hash of its code. Inside the enclave, Lit derives a key that belongs only to that exact program. Your browser fetches that program's public key from Lit and encrypts the credential to it before anything is stored. The Keychain database stores the credential only as ciphertext.

When you approve an agent, your sign-in signs an approval for that agent's public key, for that secret, with an expiry. Thirty days is the default. On every request, the program inside the enclave checks your signed approval, the agent's signature, and the expiry before it does anything.

For production credentials, use connected services. The agent calls an action such as stripe_balance, github_read_file, slack_post_message, or supabase_tables. Each action comes from a reviewed catalog, can only contact its provider's hosts, and returns a fixed set of fields. The credential is used inside the enclave and never returned. There is no call the agent can make to get it out.

Setting it up

On the agent's machine, create the agent's identity. Only the public key leaves the machine.

npx @lit-protocol/keychain init ./agent-identity.json

Then sign in at keychain.litprotocol.com with Google, a passkey, or a wallet. Add the credential as a connected service, approve the agent's public key for it, and choose an expiry. Use a key scoped to the one operation the action performs, like a Stripe restricted key with balance read only.

The agent can then call the service from the command line. In this example the credential was saved under the name STRIPE_API_KEY.

npx @lit-protocol/keychain use ./agent-identity.json STRIPE_API_KEY

Or you can add Keychain to an MCP client like Claude Code, which gets a tool for each connected service and calls it with the credential's name.

claude mcp add lit-keychain -- npx -y @lit-protocol/keychain mcp /absolute/path/agent-identity.json

The client checks the Lit endpoint's hardware attestation before it sends a request to Lit, and it refuses to send if the check fails.

What this does not protect against

Keychain can also store secrets that the agent receives in plaintext, for tools that need the raw value. Those end up on the agent's machine by design, so use connected services for anything that matters. A request that is already running when you revoke an agent may still finish. The Keychain operator can see secret names, agent public keys, and request metadata, but not values. Until a policy expires, the operator could replay an older signed policy and undo a revocation, which is a good reason to keep expiries short and to rotate the credential at the provider if you think it leaked. The hosted web app is also part of what you trust. So is the code in Lit's enclave, which is approved by a Lit Safe that needs 2 of its 4 signers. If you need more separation from the operator, you can run a verified release of the client yourself. The security model covers each of these.

Working with Lit

Lit works with teams that need agents to use production credentials without holding them. To talk about your agents and the services they use, use the Lit contact form. The list of connected services and what each one returns is at developer.litprotocol.com/keychain/connected-services.