Keys your agent never sees.
You store an API key in Infisical yourself. Your agent uses it through one command, and the value never reaches the chat, a file or your shell history. Connectors first; this is for the CLIs and APIs that need a key.
Some tools your agent drives want an API key: a long password that proves it is you. Pasting that key into the chat, or into a file, is how keys leak. This blueprint puts it somewhere safer. You keep the key in Infisical, a secrets manager with a free plan, and add it in your browser. Your agent then runs the tool through infisical run, which hands the key to that one command and nothing else. A small test proves it works without showing the key, and a second test proves your workbench's secrets guard is watching. It ends with one real key, for a tool you actually use.
The Infisical CLI, signed in as you. One project linked to your workbench. A test key your agent proves it can use without seeing it, proof the secrets guard is on, and one real key in place.
It only takes one key printed to the screen or pasted into a chat. After that, you are making new keys and checking what had access. Keeping keys out of sight from the first one is much easier.
The key lives in Infisical. infisical run -- <command> fetches it and starts that command with it. Your secrets guard allows exactly that, and blocks the commands that would print a key.
You make the account, sign in, link the folder, and add every key in the dashboard. You approve any install. The agent runs the tests and shows you the proof.
Connectors first, keys second
Most of what your agent connects to needs no key at all. Before you store anything, your agent checks which of these fits the tool you name.
- The app has a native connector. Gmail, Calendar, Drive, Slack, Notion and many more. You sign in through the browser and can revoke it in one place. Use the connector.
- The tool has its own sign-in command.
vercel login,supabase login,gh auth login. The tool keeps its own login on your computer. Fine to start, for work you watch. - The tool wants a key in a variable. A Vercel token, a Supabase access token, Exa, Firecrawl, Apify. This is where Infisical comes in, and the rest of this page.
This card adds it when a tool needs a key. Connectors cover most things with no key. The secrets guard is already in every workbench.
What happens in the thirty minutes?
Ten checkpoints, most of them short. Here are the main ones, so none of it is a stranger.
- It copies the folder to
work/keys-first-time/and asks which tool you want a key for. - It checks what is installed, and installs the Infisical CLI only if it is missing. It says what and where first.
- You sign in, in your own terminal window.
infisical loginasks you to pick US cloud, EU cloud or self-hosted, then finishes in your browser. On a computer with no browser,infisical login -isigns in from the terminal. - You make a project in the Infisical dashboard, then run
infisical initonce at the root of your workbench to link it. That writes a small file,.infisical.yaml, with the project's ID and no values. Every folder inside your workbench finds it. - You add a test key,
DEMO_KEY, in the dashboard. Any made-up text. You tell your agent only "saved". - It proves it can use the key without seeing it, then proves your secrets guard is on by trying a blocked command on purpose.
infisical --version brew install infisical/get-cli/infisical # Mac, only if missing winget install infisical # Windows, only if missing infisical login # you run this, in your own terminal infisical login status # "Authenticated as" you infisical init # you run this once, at your workbench root node prove-it.mjs DEMO_KEY # DEMO_KEY: missing infisical run -- node prove-it.mjs DEMO_KEY # DEMO_KEY: set, 28 characters infisical export --path=/guard-check # blocked by your secrets guard
The two prove-it.mjs lines are the whole idea. Outside infisical run, the key is not there. Inside, it is, and all you see is its length. The blocked infisical export proves the guard checks every command before it runs.
On Windows with Scoop: scoop bucket add org https://github.com/Infisical/scoop-infisical.git, then scoop install infisical. On any computer with Node: npm install -g @infisical/cli.
Step through the Infisical walkthrough deck, screen by screen. It goes further than this card, into machine identities for jobs that run on their own. Where it shows the older Infisical Agent writing keys to a file, skip that part: on this card your agent only ever uses infisical run.
One real key, then the payoff
Last checkpoint: one key for a tool you use. You make it on that tool's site, with the narrowest access and the shortest expiry it offers. You add it in the Infisical dashboard under the exact name the tool reads, such as VERCEL_TOKEN or SUPABASE_ACCESS_TOKEN. Your agent proves it arrived, then uses it once in a way that prints no key.
infisical run -- node prove-it.mjs VERCEL_TOKEN # VERCEL_TOKEN: set, N characters infisical run -- vercel whoami # your Vercel username, not the token
If you have a saved sign-in for this tool, this check uses it, so rely on prove-it for the key. If the tool's CLI is missing, your agent says what it would install and waits.
From then on, any command that needs it runs the same way. In Put a Page Online, your live deploy becomes:
infisical run -- vercel deploy --prod
No sign-in session, and no token in the chat, a file or your shell history.
What you can ask your agent, from now on
Five asks that work once your first key is in.
I want you to use a tool I'll name. Is there a native connector or a sign-in command for it, so I don't need a key at all? If I do need one, tell me the exact variable name it reads.
Run prove-it.mjs under infisical run for every name in my which-keys.md, and tell me which are set and which are missing. Never show me any value.
Run the command I give you through infisical run so it gets the key it needs, and tell me what came back. Use the top-level infisical run, and never print the key.
I made a new key and replaced the old one in Infisical. Prove the new one works with one harmless command, and tell me if anything that is already running needs a restart.
Help me list every key I have that is not in Infisical yet. I'll tell you which tools and where; don't open or search those files. List them by tool and name only, and add each to my which-keys.md. For each one, tell me the steps to move it and retire the old key.
Words you now own
- API key. A long password a tool gives you so a program can act as you. Also called a token. Anyone who has it can use it.
- Environment variable. A named value, such as
VERCEL_TOKEN, handed to a program when it starts. Most CLIs read their key this way. - Infisical. A secrets manager: one place to keep keys, with a web dashboard for you and a CLI for your agent.
infisical run. The command that fetches your keys and starts one other command with them. Nothing is written to a file.- Project, environment, path, name. The four coordinates that say where a key lives. None of them is the value, so they are safe to write down.
.infisical.yaml. The small fileinfisical initwrites to link a folder to a project. No values, safe to commit. Older CLIs write.infisical.json.- Secrets guard. The check in your workbench that reads every command your agent runs before it runs, and blocks the ones that would print a key.
- Connector. A built-in link from your app to another service, signed in through the browser. No key to copy.
Before you store anything
Your agent checks these with you before your first real key goes in.
- No connector covers it. If one does, use the connector and skip the key.
- The guard check passed. Your agent tried
infisical exportand it was blocked. If it was not, stop there and ask in the Lab channel. - You know the exact name the tool reads, from its docs. A near miss means the key never arrives.
- The key is as small as it can be. The narrowest access and the shortest expiry the tool offers that still does the job.
- Any key that sat in plain text gets replaced. In a
.envfile, a note, an old chat: make a new one, store that, and retire the old one.
You add keys in the Infisical dashboard, in your browser. You can also type infisical secrets set yourself, but a value typed on the command line lands in your shell's history, so the dashboard is the better habit. If an agent ever asks you for a key, the answer is no.
Fair questions
No. You add it in the dashboard. Your agent only uses it, through infisical run, and the guard blocks the commands that would show it.
It is plain text beside your work: easy to commit by accident, easy for a command to print into the chat, and one more copy to change when the key changes. Infisical keeps one copy, and infisical run leaves no file behind.
For this, yes. It includes 5 identities (people plus machines, and you are one of them), unlimited projects, 3 environments and 10 secret syncs.
op run works the same way, and the guard allows it too.
This blueprint uses your own sign-in, which is right for work you watch. A job can use infisical run with your own sign-in for now; when that sign-in runs out, the job's status says FAIL. A later card, Keys for jobs that run without you, is the long-term fix.
infisical sm run?A new name for infisical run, added in Infisical's CLI 0.44.0 (10-14-2026). The old infisical run works the same, and it is the form your secrets guard is built around, so your agent always uses it.
infisical init?Once, at the root of your workbench. Infisical looks for the link in the folder a command runs in, then in each folder above it, so every folder inside your workbench finds it.