Where does your agent's API key actually go?

You gave your AI agent an API key. That key is a password with real power: it can read your data, deploy your code, and spend your money. Do you know how many companies’ servers see it?

If you connected through an MCP directory, the honest answer might be: one more than you think.

Two ways to connect an agent

When your agent connects to a remote MCP server, there are two architectures, and they look identical from the chat window. In plain terms, either you have a direct phone line to the company you’re doing business with, or someone else’s switchboard sits in the middle of every call. The switchboard hears everything, including the password.

Direct-connect. Your client talks straight to the vendor’s endpoint:

your agent ──────────────► api.vendor.com

Your API key goes to the company you gave it to. Your tool calls travel between you and them: the SQL you run, the files you upload, the results that come back. Two parties.

Gateway-mediated. Your client talks to the directory’s gateway, which forwards to the vendor:

your agent ──► directory gateway ──► api.vendor.com

Same chat window. Same tools. One difference: every request now passes through a third company’s infrastructure. Your bearer token, your query arguments, the vendor’s responses, all of it.

This isn’t a secret or a scandal. Gateway operators describe it openly, and several advertise full call logging, usage analytics, and managed credentials as features. For some use cases those are genuinely useful. The problem isn’t that gateways exist. The problem is that most people connecting an agent don’t realize which architecture they just chose.

Why this matters more for infrastructure

For a weather-lookup tool, a middleman seeing your calls is a shrug.

For infrastructure it’s a different conversation. When your agent operates your cloud, the tool calls are your data. A db_query argument is your SQL and your schema. A storage_upload is your file. The response to a usage tool is your billing profile. If those pass through a gateway, then that operator’s security posture, retention policy, and subpoena surface just became part of your stack. And you probably never read their terms, because you never chose them on purpose.

Then there’s the key itself. Agents authenticate with long-lived bearer tokens, passwords that stay valid for months. Every extra company that handles one is another place it can leak from. Scoped keys and rotation reduce the damage. They don’t change the architecture.

The 30-second check

You don’t need anyone’s permission to find out which architecture you’re using:

1. Look at the URL your client actually connects to. Open your MCP config. If the url is the vendor’s own domain, you’re direct. If it’s the directory’s domain, there’s a middleman.
2. Read the directory’s publish page. If the pitch to server developers shows a connection diagram with the directory in the middle, or sells “call logging” and “managed credentials”, mediation is the product.
3. Check the vendor’s docs. A vendor that wants you connecting directly will publish the raw endpoint and the exact config. If you can only reach a server through a directory, ask why.

Run that check on every MCP server that touches anything you’d mind a third party reading.

Where we stand

Scalix Cloud is an agent-native platform, 50 tools behind one MCP endpoint, so we had to take a position on this early. Holding it cost us something.

Our position: we list our server only where users connect directly to our endpoint. We’re on the official MCP Registry and the community directories that publish our raw URL. We declined listings, including on some of the largest directories, where the default path would route our customers’ keys and payloads through someone else’s gateway. Fewer badges, cleaner architecture.

That’s not because gateways are evil. It’s because we sell infrastructure to people who care where their data travels, and “your agent talks to your cloud, and nobody else is on the line” is not a claim we’re willing to asterisk. We build on the same principle all the way down the stack. It’s the reason the platform runs on sovereign infrastructure in the first place. Sovereignty that stops at the agent channel isn’t sovereignty.

One key. One endpoint. Two parties.

And don’t leak the key on your own side either

While we’re being honest about key paths: the most common leak isn’t a gateway. It’s your own config. Two mistakes we see constantly.

Baking the key into the saved config. If you run --header "Authorization: Bearer $SCALIX_API_KEY" in double quotes, your shell fills in the real key before the client saves it. The raw key ends up written to disk in the config file, and in your shell history. It’s the digital equivalent of writing your PIN on the back of the card. Config files get synced between machines, published in dotfile repos, and read by every tool that touches them.

One god-key for every agent. If every tool shares one full-power key, any single leak is a full compromise, and your audit log can’t tell your agents apart. It’s one master key to the whole building, copied for every contractor.

Here’s the config we actually recommend. The real key stays in your environment or your OS keychain, and the file holds only a reference:

{
  "mcpServers": {
    "scalix": {
      "type": "http",
      "url": "https://api.scalix.world/v1/mcp",
      "headers": { "Authorization": "Bearer ${SCALIX_API_KEY}" }
    }
  }
}

Claude Code fills in ${SCALIX_API_KEY} from the environment when it reads .mcp.json, so the file never contains the secret and is safe to commit. Most modern clients support some form of environment reference. Where one doesn’t, keep the key in a secret manager and inject it at launch.

And mint the key to fit the agent, not the account. Scalix keys are scoped, so a key without services:deploy cannot deploy, through MCP or anywhere else. Read-only keys are refused every mutating tool: they can look but not touch, like giving a guest the Wi-Fi password instead of the safe combination. One key per agent keeps the blast radius small and makes the audit trail name the actual culprit.

Setup for every client is at docs.scalix.world/mcp. The handshake is open: point any MCP client at the endpoint and tools/list works without a key. You can inspect exactly what your agent would get before you trust us with anything.