Build vs Buy: The Homegrown AI Agent Credential Proxy Is Never Just a Proxy

Nearly every team that puts an AI agent in front of real APIs reaches the same conclusion within a few weeks: the agent shouldn’t hold the API key. So an engineer writes a small proxy. It takes the agent’s request, adds the Authorization header, forwards the call, and returns the response. It is a day or two of work, it demos well, and the key is out of the prompt.

That proxy is the right instinct. The trouble is what happens over the next six months, because the proxy is the only place in the system where authentication, authorization, logging and data handling all meet. Every requirement that touches an agent’s access to a system ends up landing on it.

The failure: the proxy that became a product nobody planned

Here is a common trajectory. It is a composite, not a single incident.

1. Week 1. A proxy injects one API key into outbound calls. The agent never sees the secret.
2. Month 1. A second agent needs a second system, so the proxy gains a lookup table of keys per upstream. The keys live in environment variables because that was fastest.
3. Month 2. Someone asks which agent called the billing API at 3 a.m. The proxy logs a line per request, but to a file that rotates, with no agent identity beyond the source IP.
4. Month 3. A security review notices the proxy will call any URL it is given. An agent, steered by a poisoned document, asks it to fetch an internal metadata address. The proxy complies. This is the SSRF failure agents are unusually good at triggering.
5. Month 4. A customer wants the agent to read data but never delete it. The proxy gets an if method == "DELETE" check, then a second, then a rules file nobody can test.
6. Month 6. An MCP client wants to connect, which means OAuth with PKCE, discovery metadata and refresh-token rotation. An auditor asks for evidence that access was scoped and reviewed. The proxy’s author has moved teams.

None of these steps is unreasonable on its own. Together they add up to an identity provider, a policy engine, a secrets store, an egress firewall and an audit pipeline, each built under deadline pressure by people whose job was something else.

Why each piece is harder than it looks

The security-sensitive parts are where homegrown proxies are most likely to be wrong, and wrong silently.

• Credential storage. Keys in environment variables or a config file are readable by anything with access to the process, and they tend to leak into logs and crash dumps. Encrypting them at rest brings key management, and the key ring becomes a new single point of failure.
• The login handshake. Supporting MCP means implementing the OAuth authorization flow the spec expects, including audience binding. The shortcut of forwarding the caller’s token downstream is the token passthrough anti-pattern. Getting it right means understanding token kinds, rotation and revocation.
• Policy. “Read yes, delete no” grows into per-endpoint, per-method, per-workspace rules with a defined behaviour when the policy can’t be evaluated. Fail-open versus fail-closed is a design decision, not a default.
• Egress control. An agent-driven proxy is an SSRF primitive unless it resolves and checks destinations, including redirects and DNS rebinding.
• Response handling. Data leaves through the response as readily as through the request. Redacting sensitive fields before they reach the model is its own feature, covered in the return trip problem.
• Traceability. Logging that a call happened is cheap. A tamper-evident record tying each call to an agent, a task, a policy decision and a human approval is what incident forensics and auditors need, and it is rarely retrofitted well.
• A2A and delegation. When agents call other agents, you need to know on whose behalf each call is made, which is the delegation chain problem.

A fair way to decide

Building is sometimes right. A single agent, one upstream API, no external auditors and no sensitive data can live happily with a small proxy. A rough test is to count how many of these are true for you:

• More than one agent or more than one upstream system.
• Credentials with real blast radius: payments, customer data, production infrastructure.
• A customer, regulator or auditor who will ask for evidence of access control.
• MCP or A2A clients you don’t control connecting in.
• Anyone who needs to approve sensitive actions before they run.

Two or three of those and the proxy has already stopped being a day of work. It is a security product with one part-time maintainer, and the cost shows up as engineering time diverted, audit findings, or an incident.

The business case: what a credential broker replaces

Fullmakt is a credential broker for AI agents, built to be the layer that homegrown proxies keep trying to become. In terms of the list above:

• Credentials stay server-side. Agents are given scoped access to a collection of endpoints, never the underlying secret, and secrets can live in a vault or environment reference instead of in prompts or code.
• Policy is per endpoint and method, evaluated on every call, with approvals available for sensitive actions so a human can say yes before the call runs.
• Egress is guarded against calls to internal and private addresses, and responses can be sanitized before they return to the model.
• MCP and A2A are first-class surfaces, so connecting Claude, ChatGPT or another client doesn’t mean writing your own OAuth server.
• Every call is recorded in one audit trail tied to the agent identity, so “who called what, and who approved it” is a query rather than a reconstruction.
• Pricing is usage-based, with no plans or minimums, and a no-card sandbox lets you test it against your own agents before committing. Compared with staffing the proxy, you pay for the operations you actually run.

The point isn’t that a broker is magic. It is that the work is the same either way. The question is whether your team does it once, for a living, or again every time a new requirement lands on the proxy.

FAQ

What is an AI agent credential proxy? A service that sits between an AI agent and the APIs it calls, injecting credentials into requests so the agent never holds the secret.

Should we build our own credential proxy for AI agents? For one agent, one API and low-risk data, a small proxy can be enough. Once you have several agents or systems, sensitive credentials, MCP or A2A clients, or auditors asking for evidence, the surrounding features cost more than the proxy.

What does a credential broker do that a proxy doesn’t? Beyond injecting secrets, a broker adds identity for each agent, per-endpoint policy, human approvals, egress controls, response sanitization, an audit trail and standards-based login for MCP and A2A.

What are the hidden costs of a homegrown agent proxy? Key management, OAuth and token handling, policy testing, SSRF protection, audit logging and ongoing maintenance, usually owned by people whose main job is something else.

How is Fullmakt priced? Usage-based: you’re charged per operation, such as requests through the broker and AI-generated collections, with no plans or minimums. A no-card sandbox is available.

Does a credential broker replace our identity provider? No. It governs what agents can do with other systems’ credentials. Your identity provider still handles how people sign in.