AgentValet vs API keys in .env

Forget the vendors for a minute. What AgentValet competes with in almost every real deployment is a .env file holding your Slack token, your GitHub token and your Stripe secret key, read by an agent that can act on all three. This page takes that default seriously, including where it’s honestly fine.

Two approaches, in plain words

What the .env file does well

It costs nothing. It works offline, adds no latency and no moving parts, every SDK reads it natively, and you can have an agent doing useful work three minutes after you had the idea.

For a solo experiment on your own machine, touching accounts only you own, with keys you’d rotate anyway, it’s a perfectly reasonable choice. We’d rather say that plainly than pretend every script needs governance.

What AgentValet is

AgentValet takes the keys out of the file. The agent gets an identity and a signing key that proves who it is, and nothing that opens a platform.

When it wants to act, it asks the broker, which checks what you granted, asks you first when a rule says so, and records what happened.

The question that separates them

Would you shrug at the worst thing this agent could do with those keys?

Nothing about the .env file changes when the experiment starts to matter. The agent gets a more capable model and a longer leash. A teammate copies the file. The workflow touches a customer’s data, or production, or money.

Every property the file never had (identity, scope, approval, audit, revocation) is now one you need. And the failure is quiet: a key doesn’t warn you when it’s copied, and an agent doesn’t ask before doing everything its key allows.

Keys in .env
  1. Your agent reads .env (the key sits with the agent)
  2. Calls with the raw key
  3. Real platform

Whatever the key can do, the agent can do, and so can anyone who copies the file.

Keys behind AgentValet
  1. Your agent signs a request
  2. Broker checks identity, grant and approval
  3. Credential attached in memory
  4. Real platform

The file on the agent’s machine names the agent and nothing else.

Side by side

One line per cell. Open the detail underneath for the longer version.

AgentValet compared with Raw keys in .env
AgentValetRaw keys in .env
Who is calling?One named agent, proved by its own signing key.Unknowable, because a key proves nothing about who holds it.
What can it do?Exactly what you granted, and nothing else.Everything the key allows, which is usually far more than you meant.
Risky actionsPause for your approval before they run.Run. You find out afterwards, if you find out.
What happened?An append-only row per call, with a signed receipt.Whatever each platform’s own logs show, all attributed to one shared key.
If the file leaksThere’s no platform key in it to find.The whole account, for every key in the file.
Pulling the plugRevoke the agent; the next call fails closed.Rotate every key it held, on every platform, and hope nothing cached a copy.
Cost and setupFree plan and one command; the broker adds one hop to each call.Free, instant, no added latency. This row is why it’s the default.
The detail behind 2 of these rows
What can it do?

Raw keys in .env: Most platform keys are account-wide. Your agent, a teammate’s fork and an attacker all get the same power from the same string.

If the file leaks

Raw keys in .env: .env files end up in commits, containers, logs and prompts. Ask anyone who has run a secret scanner.

Where the .env file genuinely wins

Convenience, and it isn’t close. No account, no network hop, no service that can be down. If the agent only touches things you’d shrug at losing, keep the file.

Where AgentValet wins

The moment an agent can email a customer, push to a repository someone depends on, move money or delete something you can’t restore, the question shifts from convenience to containment. That shift is the whole product.

You don’t rebuild the agent, change models or adopt a framework. The agent keeps doing what it does; it just stops holding the keys while it does it.

Which one fits

Choose API keys in .env if

  • It’s a solo experiment on accounts only you own.
  • The worst possible action is one you’d shrug at.
  • You’d rotate the keys next week anyway.

Choose AgentValet if

  • The agent can email customers, push code, move money or delete things.
  • More than one person, or more than one agent, uses the keys.
  • Someone will one day ask what the agent did.

Run both if

  • Keep low-stakes keys in the file while you move the dangerous ones behind the broker, one at a time.

Last reviewed on 24 September 2026. Spotted something wrong? Report a correction.

Want to gauge your own setup first? The scorecard maps it against the OWASP Top 10 for Agentic Applications in about two minutes, free, no email. Score your agent setup.

Keep the agent. Lose the keyring.

Register the agent you already run, move one key into the vault, and watch the same workflow go through with an audit trail behind it. If it doesn’t feel safer within the hour, go back to the .env file; it will still be there.

npx @agentvalet/register