Engram Blog · Published July 30, 2026
Your AI Can Know You Have Secrets. It Can Never Read Them.
Engram's secrets vault is zero-knowledge: keys are generated on your machine, values are AES-256-GCM encrypted before upload, and the server only ever stores ciphertext. How it works, and exactly which surfaces get it.
Sooner or later, every AI-heavy workflow hits the same awkward moment: you're mid-task, the agent needs a database URL or an API key, and the path of least resistance is to paste it into the chat. Now a credential lives in a conversation transcript — searchable, synced, and quietly resurfacing in future context windows forever.
Engram's answer is a secrets vault: a separate, zero-knowledge store that sits alongside your memory. The short version of the design: your AI can know that you have secrets, and manage them by name — but it can never read them, and neither can we.
Memory is the wrong place for secrets
Engram memory is deliberately verbatim, searchable, and designed to resurface: you save a conversation so that any future session can pull it back into context. Those are exactly the properties you want for decisions and project history — and exactly the properties you don't want for a password. Anything in memory can come back in a search result, in any connected tool, months later.
So the rule Engram now enforces all the way down to the AI's own instructions: secrets never go into memory. Every model connected to Engram is told the vault exists, where it lives, and to refuse to store credentials as memory — even when asked. The two stores have different jobs.
How the vault works
The vault is zero-knowledge: encryption and decryption happen on your machine, and only ciphertext ever crosses the network.
engram vault keygengenerates a 256-bit key that lives in your local config — it is never sent to Engram.engram vault set DATABASE_URLprompts for the value, encrypts it locally with AES-256-GCM (Web Crypto, a fresh IV per secret), and uploads only the encrypted blob.engram vault get DATABASE_URLfetches the blob and decrypts it locally with your key.
The server stores names and ciphertext. If Engram's database were dumped in its entirety, your secrets would be AES-256 noise. The flip side of zero-knowledge is worth saying plainly: if you lose your vault key, we cannot recover your secrets — there is no reset flow, because a reset flow would mean we could read them too.
The same contract holds for AI agents. An agent connected with your API key can list entries, store pre-encrypted values, and fetch blobs for client-side decryption — but a model mid-conversation never handles plaintext unless the code running on your side (the CLI, or an SDK agent you gave the key to) decrypts it. A vault your AI could read aloud would only be as trustworthy as every model, client, and log pipeline in the loop.
Who can and can't use the vault
Access follows how you connected, not who you are. The rule of thumb: if you pasted your API key to connect a tool, the vault is there; if you clicked “Sign in,” it's memory-only.
| Surface | Connection | Vault |
|---|---|---|
| Engram CLI | API key | ✅ Full — and the only place plaintext ever exists |
| Cursor | API key (.cursor/mcp.json) | ✅ Vault tools available |
| Windsurf | API key | ✅ Vault tools available |
| Claude Code | API key (claude mcp add) | ✅ Vault tools available |
| Codex | API key | ✅ Vault tools available |
| SDK / REST API | API key | ✅ Full programmatic access (agents you run) |
| ChatGPT | OAuth connector | ❌ Memory only — marketplace rules prohibit credential collection |
| Claude (claude.ai connector) | OAuth connector | ❌ Memory only — same policy class |
| Web dashboard | Browser login | ❌ Not yet — a browser-side-encryption vault UI is on the roadmap |
Why ChatGPT and Claude connectors are excluded on purpose
This isn't a missing feature — it's two deliberate walls. First, app marketplaces like ChatGPT's prohibit connected apps from collecting credentials, so exposing vault tools there would risk the listing. Second, even where it's allowed, a chat surface is the wrong trust boundary for plaintext secrets.
What those surfaces do get, as of this week: awareness. An AI connected via OAuth is explicitly told the vault exists and to route you to engram vault setinstead of improvising. (We shipped that after watching a session confidently tell a user the vault didn't exist — the model couldn't see the tools, so it reasonably concluded there were none. Models can only be as honest as what you tell them.)
Getting started in two minutes
npm install -g @getengram/cli
engram login # or: engram auth login <api-key>
engram vault keygen --save # generates your local key — back it up!
engram vault set OPENAI_KEY # prompts, encrypts locally, uploads ciphertext
engram vault list
engram vault get OPENAI_KEYFrom there, agents you run with the SDK can resolve secrets by name with the key you give them — and every AI connected to your Engram, on every surface, now knows the difference between a memory and a secret.
Memory for everything. A vault for the things that aren't memories.
Free tier, no credit card. The vault ships with the CLI.