KeyForge

Keys that can’t leak. Logs that can’t lie.

KeyForge started the way most infrastructure companies do: with an incident. In late 2025, our founding team was running a fleet of research agents for a previous product. One agent, manipulated through a poisoned webpage, dumped its environment — including a raw provider API key — into a public scratchpad. The spend was caught in hours. The uncomfortable questions lasted much longer: what exactly did that key do before we noticed? Could we prove our own logs hadn’t been touched?

We couldn’t. Nobody could. Every gateway we evaluated stored real keys (encrypted, sure — but real), treated budgets as dashboards rather than enforcement, and kept logs that any attacker with write access could silently rewrite. The tooling was built for teams of humans calling APIs. It was never built for autonomous processes that ingest untrusted content and act on it.

So we built the gateway we needed: virtual keys that give agents a credential with no relationship to the real one; budgets and rate limits enforced at the gateway, not politely suggested; and an HMAC hash-chained audit trail where tampering is mathematically detectable. When the LiteLLM supply-chain compromise hit in March 2026, it confirmed the thesis — the question is no longer if something in your agent stack gets compromised, but whether you can contain and prove what happened.

We’re developers, and it shows: KeyForge is OpenAI-compatible so migration is a base-URL change, the free tier includes the full security stack, and hard limits mean your bill can never surprise you. Agents are going to run more of the world’s software. The keys they hold should be built for that.

Zero-trust by default

Assume the agent will be manipulated. Design so it doesn’t matter.

Developer-first

One-line migration, honest docs, flat pricing, no sales-call paywall.

Verify, don’t trust

Every claim we make about your traffic is cryptographically checkable.

Join the teams securing their agents