Lit Protocol gives an agent a secret it never sees, and its record has no delegated identity

Lit Protocol gives an agent a secret it never sees, and its record has no delegated identity

Lit Protocol has written the clearest short answer to a problem this series ran into itself last week. In How to give Claude Code and MCP servers secrets without handing them the keys, the team opens with the rule: “The safest way to give an agent access to a secret is to never give it the secret.” The reason is that “Agents log everything. Their transcripts get saved, summarized, and sometimes shared.” Agent Keychain, an open-source app built on Lit, stores a credential encrypted in the browser, lets the owner approve an agent’s public key for it with an expiry, and then serves it in one of two modes. Stored secrets are decrypted on the agent’s machine and passed to a child process. Connected services run a versioned action such as a Stripe balance check inside a secure enclave with the credential, and “the agent gets the balance. It does not get the key.”

There are no adoption figures, only a price and a threat model, and both are stated plainly. Keychain is free for five secrets and ten dollars a month for up to a thousand. The operator “cannot decrypt a secret, because it does not have your key,” cannot approve or extend an approval, and cannot change what an action returns because the enclave signs the response. What the operator can do is refuse service or keep serving an older approval until it expires, and revocation “takes effect on the next request. Anything the agent already received stays with the agent.” The post also names what the design does not protect against: a stored secret handed to a child process is plaintext on that machine, and a connected service still trusts the upstream provider with the credential.

The catalog has the thinner side of this story. The Lit Protocol provider page lists 5 API pages, and the enclave-run actions the post describes are the surface of the Lit Protocol Actions API, with the keys and approvals under the Lit Protocol Account Management API. The agentic access profile maps 37 operations, 22 of them acting. On the Agent Readiness score, spec presence, agentic access and the rate limit signal are lit. Keychain’s MCP server runs locally from an npm package, so it does not light the MCP server dimension on the company’s record.

The Kin Score is 20.7, emerging band, carried by discoverability at 73.2 and contract quality at 33.1, with access clarity at 13.2, developer ergonomics at 11.9 and operational transparency at 7.9. The Agent Readiness score is 15.4, agent-aware. Auth clarity is unlit, and so is delegated identity, on the record of a company whose product is delegated use of a credential by an agent that is never shown it. The post describes a precise model of who can see what, and the public API contract does not yet carry it. Last week the A2A CLI printed an entire environment file into an agent transcript in this series. Lit’s rule would have made that file empty. The record shows the rule written for customers before it was written into the contract.

← Google Cloud puts hundreds of gcloud commands behind two MCP tools, and BigQuery's record has no server
Supabase gives every app an MCP server, and its own access clarity scores 34 →