Programmable credential access

A password manager for machines.

Give your AI agents API keys without giving them your API keys. Secrets are sealed inside a hardware enclave (TEE) and released only under policies you control — allowlists, read quotas, expiry — or configured to never leave the enclave at all.

import { LitSecrets } from './sdk/lit-secrets.js';

const secrets = new LitSecrets({
  usageApiKey: process.env.LIT_SECRETS_KEY,
});

// Policy checked, decrypted in the TEE,
// returned straight to this agent.
const key = await secrets.get('OPENAI_API_KEY');

How it works

One credential per agent. Plaintext never touches our servers after import — the decrypt happens inside the enclave and goes straight to the caller.

01 · SEAL

Store a secret

Your secret is encrypted to a vault key that never leaves the enclave. We store ciphertext, versions, and policy — never the value.

02 · GRANT

Policy decides

An agent requests access with its own key. We evaluate your policy — agent allowlist, reads per day, expiry — and sign a grant valid for ~2 minutes. Every allow and deny is audit-logged.

03 · REDEEM IN THE TEE

Decrypt in hardware

The agent redeems the grant against a pinned, publicly auditable program running in the enclave. It verifies the grant, decrypts, and returns the value directly to the agent.

Two release tiers

Start with the easy path. Ratchet up to the tier no conventional secrets manager can offer.

plaintext

Agents may read the value

The default. Authorized agents fetch the secret and use it locally — the simplest developer experience, gated by your policy and fully audit-logged.

  • Per-secret agent allowlists
  • Read quotas and hard expiry
  • Instant key revocation
in_tee_only

The value never leaves the enclave

Only programs you explicitly approve — identified by their immutable content hash — can decrypt, and only inside the TEE. Your agent calls Stripe with a key it can never see. Nobody can read it out. Including us.

  • Approve code, not people
  • Auditable by content hash (IPFS CID)
  • Use-without-reveal for high-value keys

Security model

Built on Lit Protocol's TEE network — Intel TDX enclaves with remote attestation, on-chain authorization, and content-addressed programs.

your secret ──seal──▶ AES-256-GCM under a key derived inside the TEE (never exported) who can decrypt ──── recorded on-chain: only programs in your vault group, by content hash each read ─────── requires a short-lived signed grant, verified inside the enclave our database ───── holds ciphertext + policy only; a full breach reveals no secret values the hardware ───── remotely attestable: verify the exact code and enclave serving you

Auditable programs

The encrypt and reader programs are pinned by content hash. Anyone can read the exact code allowed to touch your vault.

Complete audit trail

Every grant and denial, per secret and per agent, with the policy reason. Rotation keeps prior versions addressable.

One-step revocation

Revoking an agent kills its key at the enclave network too — not just in our records.

Built for agents, by design

Point your coding agent at this site and it can onboard itself: machine-readable docs, a zero-dependency SDK, and a copy-paste skill.

/llms.txt

Machine-readable index of everything on this site, in the llms.txt standard.

/SKILL.md

An agent playbook: authorize, store secrets, mint runtime keys, read at runtime.

/sdk/lit-secrets.js

Zero-dependency ES module for Node 18+, Deno, Bun, and browsers.