Why Your AI Agents Need Virtual Keys, Not Raw API Keys

There is a pattern quietly repeating across the industry right now: a team ships an autonomous agent, and to make it work, they paste a raw OpenAI or Anthropic API key into its environment. The agent works. Everyone moves on. And an unattended, internet-connected process is now holding a credential that can spend real money against your provider account — with no scoping, no independent budget, and no way to know afterwards exactly what it did.

This was tolerable when the “user” of an API key was a human developer or a single backend service. It stops being tolerable when the key holder is an autonomous agent: a process that browses the web, executes tools, ingests untrusted content, and — crucially — can be manipulated by that content. Prompt injection is not a theoretical attack. An agent that can read a malicious webpage and also read its own environment variables is one clever payload away from exfiltrating your production credentials.

The blast radius problem

Think about what a leaked raw key actually costs you. First, direct spend: the attacker can burn tokens against your account until you notice — and “noticing” usually means the invoice. Second, rotation pain: revoking a shared raw key breaks every service that uses it, so teams delay rotation, which extends the exposure window. Third, forensic blindness: provider dashboards show aggregate usage, not which process made which call, so you often cannot even establish what the attacker did with your key.

The March 2026 LiteLLM supply chain compromise made this concrete. Trojanized PyPI releases harvested SSH keys, cloud credentials, and Kubernetes secrets from the very machines running LLM gateway software. Any raw provider key sitting in those environments was part of the haul. The lesson is not “don’t use open source” — it is that credentials sitting in agent-adjacent environments will eventually be read by something you didn’t intend.

Encryption at rest is not abstraction

Most gateways answer this with a vault: your provider keys are stored encrypted, and the gateway decrypts them to route requests. That is better than plaintext in a .env file, but it is storage security, not key abstraction. Portkey’s “virtual keys”, for instance, are encrypted wrappers around real provider keys — anyone or anything with configuration-level access is still one step from the underlying credential. The agent-facing surface hasn’t changed.

True virtual keys work differently. The agent receives a vk_ token that has no mathematical relationship to any provider credential. When a request arrives at the gateway, the vk_ key is resolved to a policy — which models it may call, how many requests it has left this month, how many dollars it may spend — and only then is the real provider key injected, server-side, for the outbound call. The agent cannot leak what it never sees. A stolen vk_ key is worth exactly its remaining quota, which you set, and which you can zero out with one click.

What per-key isolation buys you

Once keys are virtual, each one becomes a policy boundary. Your production research agent gets 20,000 requests and a $50 cap. The staging support bot gets 5,000 and $15. A contractor’s experiment gets 500 requests that expire on Friday. Every one of these is enforced at the gateway — not by hoping the agent’s own code respects a config value — and each key writes to its own HMAC hash-chained audit trail, so “what did this agent do?” has a cryptographically verifiable answer.

Revocation becomes surgical too. Kill the compromised key; every other agent keeps running. No shared-secret rotation, no redeploys, no 2 a.m. incident bridge deciding which services can tolerate downtime.

The migration is one line

Because KeyForge exposes an OpenAI-compatible API, adopting virtual keys is a base-URL change and a key swap: point your client at the gateway, replace sk_ with vk_, done. Your agent code, SDKs, and prompts stay identical. From that moment, real credentials live encrypted in the vault, every call is metered against per-key budgets, and the audit chain records everything tamper-evidently.

Agents are only getting more autonomous. The credential model they inherit should assume they will eventually be manipulated — and make sure that when it happens, the attacker walks away with a capped, revocable, fully-audited token instead of your provider account. You can create your first three virtual keys free — no card required.