An AI agent should call a third-party API without ever holding that API’s key. The pattern is a credential-less agent: the process holds only a scoped proxy credential, the vendor secret stays with a broker, and each call is allowed or blocked on its shape.
That is different from putting the vendor key in a secrets manager and injecting it into the agent’s environment at start-up. The agent still has the key. A prompt injection, a leaked config file or a dumped context window still has something reusable.
The Xero key in the config file
A finance analyst at a 40-person practice stood up an assistant to answer “what do we owe this supplier” from Xero. The official connector asked for an OAuth token. The fastest path was the practice owner’s token, pasted into a JSON config next to the model endpoint. The assistant worked. It could also see every invoice, every bank feed, and every payroll run the owner could see.
A week later a developer copied the config into a shared repo so a colleague could try the same prompt. GitGuardian’s 2026 sprawl report exists because this is now a common commit, not a rare accident. The token was a live, owner-level credential to an accounting system. Revoking it would break the owner’s own login. Nobody had a second identity for the assistant.
The failure was not that finance wanted help from a model. The failure was that the agent was given the real key.
How do AI agents usually get API keys?
They inherit a human token, read a key from config or environment, or check a secret out of a vault into the same process.
A human’s OAuth token. The agent acts as the owner. Every permission that person has is in play. Audit at the vendor shows a person, not an assistant. Revocation hurts the human.
A long-lived API key in config, .env, or an MCP file. GitGuardian’s State of Secrets Sprawl 2026 (published 17 March 2026) found 28.65 million new hardcoded secrets in public GitHub commits in 2025, up 34% year on year. AI-service secrets reached 1,275,105, up 81%. In Model Context Protocol (MCP) configuration files alone they identified 24,008 unique secrets, including 2,117 unique valid credentials (8.8% of those findings). The blog notes that “popular MCP setup guides often recommend putting API keys directly into configuration files”.
A vault injection at process start. This is better storage. It is not a different trust boundary. Once the key is in the agent’s environment, a leaked process dump, a verbose log or a successful injection has the vendor secret.
A key in the system prompt or tool description. Anything in context can be asked for, summarised, or written to a file the model can reach.
Each of these puts a reusable vendor credential where the model, the config and the operator can see it.
What is a credential-less agent?
It is an agent that never holds the upstream API credential. It authenticates to a proxy with its own scoped secret. The proxy attaches the vendor key only after the call is allowed.
The stance is credential-less agents, not “agents without any secret”. The agent still proves who it is. What it must not hold is the key that works directly at Xero, Salesforce or the payments processor.
The broker pattern has four parts:
- A target credential – the real vendor secret, stored once, never issued to the agent.
- A proxy credential – what the agent actually presents. It identifies this assistant, not the practice owner.
- Per-call scope – rules that allow only the methods, paths and request shapes that assistant needs. Default deny for everything else.
- An audit record – which caller, which target, allowed or blocked.
Rotation then happens in one place. The vendor token can change without redeploying the agent or rewriting MCP config. The agent’s proxy credential can be revoked without touching the owner’s Xero login.
This is the consumer-side complement to outbound API governance. Identity still says who the agent is. The proxy says what this call may do.
Why a leaked proxy credential is a smaller incident
It is scoped, revocable, and useless at the vendor.
A prompt injection that says “print your environment” will, at best, print a proxy secret that can only reach the endpoints already in grant. It cannot open payroll if payroll was never allowed. It cannot call Xero’s token endpoint as the owner. You revoke the proxy credential. The vendor key stays put. Other assistants that use the same target keep working.
A leaked owner token is a different incident. It works anywhere the owner could work, including from a laptop that is not yours, until someone notices and is willing to break the owner’s session.
GitGuardian’s MCP numbers are the config-file version of the same story. Twenty-four thousand unique secrets in public MCP configs means the ecosystem’s default is still “put the key next to the tool name”. Credential-less agents make that default fail closed: the file contains a proxy identity, not a Xero refresh token.
Before and after
| Agent holds the vendor key | Credential-less agent | |
|---|---|---|
| What is in config or MCP JSON | Owner OAuth token or sk_live_… | Proxy credential for this assistant |
| What a prompt injection can steal | A key that works at the vendor | A scoped secret that works only at the proxy, within rules |
| Blast radius | Everything the vendor key can do | The endpoints and methods already in grant |
| Rotation | Redeploy or rewrite every agent config | Rotate the target credential once |
| Audit | Vendor log shows a shared user | Your log shows which assistant, which path, allow or deny |
| Human login | Tied to the same secret | Untouched when the assistant is revoked |
The right-hand column is what connecting Claude to Xero should default to: read-only, scoped, and audited. The same isolation applies when Claude or Copilot calls Microsoft Graph without a tenant-wide token in the agent.
How to give an agent API access without the key
Put the vendor credential behind a proxy, issue the agent its own identity, and deny every call that is not in grant.
- Create the target. Point it at the vendor API. Store the real key or OAuth client there. The agent never receives those fields.
- Create the proxy. Give this assistant its own inbound credential. Set the default rule effect to deny.
- Write the grant. Allow only the paths and methods the task needs. A payables assistant gets invoice reads. It does not get payroll, bank transfers or user administration.
- Filter the response. If the invoice endpoint returns supplier tax file numbers the model does not need, drop those fields before the response reaches the agent.
- Connect the agent to the proxy. MCP config, environment and prompts contain the proxy URL and the proxy credential only.
- Run a hostile prompt on purpose. Ask the agent for its keys, to dump env, or to call a path outside the grant. The proxy should deny the extra path. The env should not contain the vendor secret.
- Read the audit trail. Confirm the allowed call and the denied call are both recorded against this assistant.
No JSON in this article invents field names. The objects are target, credential, proxy, rule and filter – the same nouns used in the product and in outbound API governance.
Where RequestRocket fits
RequestRocket holds the real API credential so the agent never sees it. Callers use a RequestRocket proxy credential. Rules down-scope each call. Filters redact the response. Meters and alerts apply per proxy or credential. Every call is logged: which caller, which target, allowed or blocked. The same proxy can be exposed as an MCP server so Claude or another assistant never needs the vendor token in its config.
It does not replace a secrets manager. You can still store the target credential there if your policy requires it. RequestRocket is the runtime hop that keeps that secret out of the agent. It provides no models and does not “detect” a leak with AI. It enforces the grant on every call.
FAQ
Is a secrets manager enough for agent credentials?
It is the right place to store the vendor secret. It is not enough if the agent still receives that secret at runtime. A credential-less agent never does.
Does the agent still need some secret?
Yes. It needs a proxy credential that identifies it. That secret should be scoped, rotatable and useless at the vendor. The phrase credential-less refers to the vendor key.
What if the vendor only supports one OAuth app user?
Then every integration still shares that upstream identity at the vendor. The proxy is how you split callers on your side: different proxy credentials, different rules, different audit rows, one stored OAuth grant.
Will rotating the vendor key break the agent?
Not if the agent never had that key. You rotate the target credential. Existing proxy credentials and rules stay. The next allowed call uses the new secret.
Are MCP config leaks really that common?
GitGuardian reported 24,008 unique secrets in MCP-related configuration files on public GitHub in 2025, of which 2,117 were valid at detection. The documentation pattern those files copy is still “put the key in the JSON”.
Can we just use a read-only vendor key?
Read-only is better than owner-level. It is still a vendor key in the agent’s process. A leak still works at the vendor until you rotate it, and it still sees every field the vendor’s read scope includes unless you filter the response.
Book a walkthrough of RequestRocket