Geslar logo
Geslar
2 min read

We said: rules before code. Here's the code.

Geslar CLI is here — your AI agent runs your app with real secrets, without ever seeing them.

The problem we're solving
A few weeks ago we published a five-rule doctrine for how AI tools should access passwords — before we'd written a single line of code. We said rules come before code, so feel free to hold us to it.

Today, the code is here.

AI agents — Claude Code, Cursor and similar tools — increasingly run our apps, tests and deploys. To do that, they need access to secrets: database passwords, API keys, tokens. The usual way this gets solved today is simply handing the secret to the agent. Into its context. Where the model reads it, where it stays in the conversation history, and where a prompt injection attack can extract it — and no reliable defence against that exists yet.

We started from the opposite assumption: a secret must never enter the AI context. The agent may orchestrate — start, connect, execute — but the secret's value gets injected directly into the program that needs it, never into the conversation with the model.
How Geslar CLI does it
Your .env file no longer holds secrets, just references:

DATABASE_URL=geslar://Work/Database/url
STRIPE_KEY=geslar://Work/Stripe/secret_key
You can safely commit that file — there's nothing secret in it. You run the app like this:

geslar run --env-file .env -- npm start

Geslar resolves the references and decrypts the values on your machine (the server never sees your keys — the same zero-knowledge principle as the rest of Geslar), and injects them directly into the process you're running. The secrets exist only in that process's memory, while it runs. If any reference is invalid — nothing starts (better to fail loudly than run on half a configuration).
Throughout all of this, the agent only ever sees the reference (geslar://…) and the run's result. The value never passes through it — so prompt injection can't extract it either, because the agent simply never has it.
Five rules, now in code
The doctrine is no longer a manifesto — it's how the tool behaves:
A secret never enters the AI context
geslar run injects into the process, not the conversation.
Every access is approved
A new device is authorized by your approval in the console, with a fresh 2FA check.
Least privilege, limited duration
Unlocking has a deadline (TTL); locking is instant.
Decryption only on your device
Keys never leave your computer.
Honest about scope
This is v0.1.0 and it's deliberately developer-first. It works with cloud accounts; every new device requires your human approval (service-account tokens for CI are coming next); the Windows binary isn't signed yet; macOS is npm-only for now. What works today works end to end — and the team layer (service accounts and an audit trail ready for NIS2) is next up.
Start in a minute
npm install -g @geslar/cli

Full documentation, quickstart and binaries are at docs.geslar.app.
We're building Geslar so an AI agent can work for you — but must never see your passwords. If you're letting AI tools near your credentials, give it a try and tell us where it still hurts.

Geslar — your data, your control. Free.

Download Geslar →

Author
Daniel Legin
Daniel Legin builds Geslar — a free password generator and manager made in Croatia.
More about Geslar →