DEV Community

Tolga Coskun
Tolga Coskun

Posted on Fully Autonomous

Your coding agent doesn't need your real API key

A post on r/ClaudeCode this week asked two good questions about coding agents and credentials:

  1. Could the agent see a fake secret, with the real one swapped back in only on the way to the server?
  2. Could the agent reach only the hosts and calls you gave it permission for?

For any API that takes its key in a header (OpenAI, Anthropic, most SaaS and internal APIs), you can do both today with a gateway between the agent and the API. Below is what that looks like, with real output, and the parts it does not cover.

1. The agent never holds the real key

You store the real key in the gateway once. The agent gets its own gateway key instead. When the agent calls the API through the gateway, the gateway removes the agent's key and adds the real one.

I ran this with Odile Gate (hosted, free for 3 agents), pointing a project at an echo server so I could see exactly what arrived on the other side. The agent only had its Gate key. This is what the "server" received:

upstream url: https://httpbin.org/anything/chat/completions
upstream saw Authorization: Bearer sk-demo-not-real
Enter fullscreen mode Exit fullscreen mode

If that agent's key leaks, you revoke that one key. The real key, and every other agent, keep working. Rotating the real key is one admin call; the agents never see the change:

{"ok":true,"header_name":"Authorization","has_secret":true}
upstream saw Authorization: Bearer sk-demo-rotated
Enter fullscreen mode Exit fullscreen mode

2. Only the calls you allowed

Each agent gets a list of the calls it may make, for example only POST /chat/completions. Anything else stops at the gateway:

HTTP/2 403
x-gate-refused: route_not_allowed
Enter fullscreen mode Exit fullscreen mode

For a model API you can also list the models an agent may use. Another model is refused before the provider sees the call:

HTTP/2 403
x-gate-refused: model_not_allowed
{"error":"support-agent may not use the model gpt-5-pro","allowed":["gpt-4.1-mini"]}
Enter fullscreen mode Exit fullscreen mode

And an agent stuck in a loop, sending the same request again and again, is stopped on the tenth identical call inside ten seconds:

HTTP/2 429  x-odile-gate-loop-detected: true
Enter fullscreen mode Exit fullscreen mode

What this does not cover

Being straight about the limits matters more than the demo:

  • AWS-style credentials. AWS (and similar) sign every request with the secret, so a gateway cannot simply swap a placeholder for the real key. That needs a proxy that re-signs requests, which Gate does not do.
  • Any host on the internet. A gateway protects the APIs you put behind it. It is not an egress firewall: it does not stop an agent from curling some other website. For that you need a network allow-list where the agent runs (a sandbox or container with outbound rules).
  • Data the agent already knows. The tweet in that thread was about an agent putting personal data into HTTP headers because a site asked it to. A gateway cannot stop the agent sending what is already in its context to a site outside the gateway. What it does change: the real API key is not in the agent's context to begin with, so it cannot be one of the things that leaks.

Setting it up

Three calls: a project holding the real key, one app (key) per agent with its allowed calls, then point the agent's SDK base URL at the gateway with its own key. The full guide, including Anthropic: https://gate.odilelabs.com/guides/ai-model-api-key-gateway

Gate never stores prompts or answers; the audit log keeps the time, agent, call, status, duration, body size and a hash. Free covers 3 agents and 10,000 calls a month; Pro is $29 a month for 25 agents and 1,000,000 calls.

Top comments (0)