Your AI Agent Is One Bad Tool Call Away From Draining Your OpenRouter Balance
The third config file is the one that makes you pause.
The first key felt normal. Claude Code needed access, so you pasted the OpenRouter key and kept moving. The second one felt slightly worse. Codex CLI needed the same thing. By the third agent, the shape of the problem is obvious.
You are not configuring tools anymore.
You are copying the same account credential into a growing pile of software you do not fully control.
That is the plaintext-password problem, updated for AI agents.
The raw API key in your agent config is not just a credential. It is your balance, your provider account, your rate limits, your billing method, and sometimes your customer data. If the agent can read it, anything inside that agent's blast radius may be able to read it too.
That is why AI agent API key security has to move past “hide the key better.” The better answer is simpler: do not give the agent the real key.
The key is not only exposed to the agent
Most builders talk about agent trust as if the agent is one thing.
It is not.
A modern agent is a harness, a model, prompts, dependency packages, MCP tools, shell commands, browser sessions, local files, logs, cloud sync, and whatever content it reads before taking action. When you paste sk-...REDACTED into that world, you are not handing it to one clean process with perfect manners.
You are placing it where many things can touch it.
A dependency can read environment variables. A tool can inspect a config file. A prompt-injected webpage can ask the agent to dump secrets. A shell command can print history. A debug log can capture the header. A backup client can sync the file. A Git mistake can publish the .env.
None of those are exotic movie-plot attacks. Token-stealing malware exists. Leaked .env files exist. Accidentally committed credentials exist. Secret-scanning tools exist because this failure class is common enough to be boring.
The AI-agent wrinkle is speed.
A leaked key from a normal script is bad. A leaked key from an agent that can call tools, loop, browse, clone repos, run shell commands, and spend tokens while you sleep is worse. It can turn a small configuration mistake into a provider-balance problem before you are back at the keyboard.
If that key is an OpenRouter key with broad spend access, the failure mode is not abstract. Your balance drains.
Rotation is not a strategy
The usual answer is key rotation.
Rotate faster. Rotate when something looks wrong. Rotate after a breach. Rotate all the keys and update every service.
Fine. You should know how to rotate keys.
But rotation is a cleanup motion, not a control system.
If three agents share the same OpenRouter key, deleting that provider key cuts off all three agents at once. The good one stops. The bad one stops. The one halfway through a deploy stops. Then you have to paste the replacement key into every place the old one lived.
That is whack-a-mole with billing attached.
Provider dashboards are built around provider keys. They can usually revoke the provider credential. They do not know that your “research-agent,” “codex-fixer,” and “crawler-bot” are three different operational actors with different jobs and different risk levels.
A cloud secret manager can improve storage. It does not automatically solve the last inch.
At some point, the plaintext key still gets handed to the agent, injected into an environment, mounted into a process, or made available to a tool. The vault is safer at rest. The agent still receives the dangerous object at runtime.
That is the gap.
Agents should get disposable keys
The principle is not complicated.
Your AI agent should not hold the real provider key. It should hold a scoped, revocable proxy credential.
That proxy key should be specific to one agent. It should carry only the permissions that agent needs. It should be easy to kill without rotating every other agent. It should leave an audit trail showing what it tried to do.
In plain English: give the agent a leash, not the house keys.
This is the same operational idea behind least privilege, but applied to local agent work. Your coding agent does not need the same credential as your research agent. Your experimental MCP harness does not need the same credential as your production deploy assistant. Your throwaway weekend agent should not get a key that can silently burn the same account balance as the agent you trust every day.
Per-agent isolation changes the failure mode.
If one agent gets prompt-injected, you revoke that agent's proxy key. The next call is denied. The other agents keep working. Your real provider key does not get copied into another config file. Your audit trail tells you what happened.
That is the control surface builders need.
Not because agents are evil.
Because agents are useful enough to deserve real blast-radius controls.
Where Agent Master Key fits
Agent Master Key is my Mac-native implementation of that pattern.
It is a shipped, notarized macOS app for Apple Silicon Macs running macOS 14 or newer. The current launch build is v0.0.33. It is free during the current limited launch window, with no card required.
The product does one specific job: it keeps your real API keys in a local encrypted vault on your Mac, then hands each agent its own scoped, revocable amk_live_... key.
The vault uses scrypt and AES-256-GCM locally. Agents call a broker on 127.0.0.1. Your real keys do not sit in agent config files, .env files, or shell history. AMK does not upload, store, or see your keys.
That last sentence matters, so here is the exact security posture: local-first custody, no cloud secret store, same-user Mac trust boundary — independent review planned, not yet performed.
That is not a magic sentence. It is a boundary.
AMK makes no outside certification claim. It is a local custody tool for solo AI builder-operators who already trust their own Mac more than another cloud secret store.
It currently supports 23 agent harnesses, including Claude Code, Cursor, and Codex CLI. The right way to read that is practical, not mystical: AMK is built for the tools builders are already wiring by hand.
The five-minute path
The workflow is intentionally boring.
Install AMK from the direct Mac download. Create the vault. Paste a provider key once, such as an OpenRouter or OpenAI key. Then create a scoped key for one agent.
The agent receives something shaped like this:
OPENROUTER_API_KEY=amk_live_REDACTED_AGENT_KEY
Your real key stays out of the config:
# Do not put this in the agent config
OPENROUTER_API_KEY=sk-REDACTED_REAL_PROVIDER_KEY
Point the agent at the local broker on 127.0.0.1. Run the agent normally. When it makes a call, AMK records it in the local audit trail.
Then do the test that matters.
Revoke that one agent key.
The next call from that agent is denied.
You did not rotate the provider key. You did not break every other agent. You did not hunt through shell history or old .env files trying to remember where the real key landed. You killed one disposable credential.
That is the whole point.
The product is not trying to make agents harmless. No tool can do that. It is trying to make one agent's mistake smaller, faster to see, and easier to stop.
What this does not prove
Honesty is part of the product.
AMK does not prove that every connector in every harness has been battle-tested under every weird local setup. It does not mean your Mac is invincible. It does not remove the need to use provider-side spend limits, least-privilege provider keys, secret scanning, careful MCP tool selection, and boring operational judgment.
You still own the machine. You still choose which agents to run. You still decide which tools deserve access.
AMK changes the credential handoff.
Instead of asking, “Which agent gets my real key?” you ask, “Which disposable key does this agent get, and how fast can I revoke it?”
That is a better question.
What you should actually do
If you run one AI agent, audit where its raw provider keys live.
If you run two or more, stop sharing one account key across all of them. Put each agent behind its own revocable credential. Keep the real provider key out of agent config files. Check your shell history. Check your .env files. Check your MCP configs. Check anything synced to cloud backup.
If you use OpenRouter, OpenAI, Anthropic, Firecrawl, X, analytics APIs, or similar paid services, treat the key like spend authority. Because it is.
You do not need a complicated security program to start.
You need one rule: agents get disposable keys.
Agent Master Key is one implementation for Mac builders who want that rule enforced locally.
Free on Mac during the launch window — put your real keys in a vault and hand your agents disposable ones: https://agentmasterkey.com
If this threat model is useful, read the supporting guides on how to store API keys for AI agents safely, how to revoke an AI agent's access, and credential sprawl in AI agents. They cover the operating habit behind the tool.
The AMA Report cuts through the noise — practical intelligence for business operators making real decisions. Subscribe free →