The real problem

`.env` files work for apps. They break down for agents.

.env files expose too much, too early

A plain .env file makes every listed secret available to the running process up front. For AI-assisted coding workflows, that means the agent operates inside a context where raw tokens may already be present whether they are needed or not. This is convenient, but it is a weak security default.

Environment variables carry weak intent

Token names rarely explain what access is safe, when the token should be used, or what domains and operations actually match the task at hand.

Secrets leak through normal developer workflows

When secrets live in env files and process environments, they can spill into logs, shell history, crash reports, copied configuration, debugging output, and screenshots. The problem is not only malicious exfiltration; it is ordinary operational leakage.

How KeyLore works

Separate the secret, the explanation, and the action.

1

Store secrets separately from metadata

KeyLore keeps raw credential values distinct from the metadata shown to AI tools. The metadata can describe what a credential is for, which service it targets, and when to use it, without exposing the token itself.

2

Let agents search the AI-facing catalog

Supported clients such as Codex, Gemini CLI, Claude CLI, and generic MCP clients can inspect the metadata layer to discover available credentials. This gives the agent a structured way to find the right option for a task.

3

Broker access when a tool actually needs it

When the workflow requires a credential, the client requests brokered access through KeyLore rather than reading a raw token from process state. The agent works through the broker instead of being handed the underlying value.

4

Keep the default local-first

The standard install runs locally on your machine. You install the package, start the local HTTP service, and open the UI in your browser. That keeps the initial trust model simple and inspectable.

Why KeyLore beats plain .env

Use brokered credential access, not a process-wide secret dump.

For AI coding agents, the real question is not whether credentials exist. It is how much of them the model-facing process can see by default, and whether the system expresses intent clearly enough for safe use.

Plain `.env`

Loads raw secrets directly into the process environment
Makes unrelated credentials available even when a task needs only one
Relies on variable names as the main hint about purpose and scope
Commonly leaks through logs, shells, crashes, and copied config files

Why KeyLore over `.env` for AI agents

Separates raw secret values from AI-visible metadata
Lets agents discover credentials through descriptive metadata rather than guessing from env var names
Supports brokered access instead of direct token handling by the model-facing client
Reduces unnecessary secret exposure during routine coding workflows
Works with Codex, Gemini CLI, Claude CLI, and generic MCP clients

KeyLore is not just a secret store. It is a secret store plus contextual retrieval plus governed execution for AI tools.

See the model

What the AI sees vs what stays secret.

What the agent sees in KeyLore is not the same as what the secret is. The AI-visible layer is metadata: enough to identify the right credential for a task, not a dump of raw token material.

What the model sees

{
  "id": "github-readonly-prod",
  "service": "github",
  "allowedDomains": ["api.github.com"],
  "permittedOperations": ["http.get"],
  "userContext": "Main team GitHub read token",
  "llmContext": "Use for repo metadata, issues, pull requests, and rate-limit reads"
}

What stays out of the prompt path

{
  "rawToken": "never returned to the agent",
  "bindingSecret": "stored separately in KeyLore",
  "envLeakRisk": "reduced by avoiding .env exposure"
}

Start from the page you actually need

A content surface built around search intent.

Docs

Install, architecture, and first-run path

Start with the local-first setup and the shortest route to a working MCP connection.

Integrations

Codex, Gemini CLI, Claude CLI, and generic MCP

Client-specific setup pages with configuration guidance and safe defaults.

Security

MCP risks, threat model, and why .env is the wrong default

Understand the security boundary KeyLore creates and how to explain it to reviewers.

Knowledge Base

Common questions, setup failures, and migration answers

Problem-led troubleshooting content that matches what developers actually search for.

Install

From zero to running in minutes.

The default local-first install is simple: install the package globally, start the background service, and open the browser UI on your machine. From there you can add a token, define metadata, test brokered access, and connect your AI tool.

Install from npm Read the docs hub

npm install -g @simonsbs/keylore
keylore-http start
# browser: http://127.0.0.1:8787/

Common questions

What teams usually want to know first.

Does KeyLore replace secret managers?

No. Its role is narrower: improving how credentials are handled in local AI-assisted development workflows so agents do not need direct raw-token possession by default.

Does the AI ever see the token?

In the brokered path, the AI sees metadata and the result of the governed action, not the raw token value itself.

Why is metadata so important?

Metadata gives the agent structured information about what a credential is for. That is much more reliable than asking the model to infer intent from environment variable names alone.

.env files work for apps. They break down for agents.