AI Agents Will Leak Your API Keys. Here Is the Architecture That Stops It.

OpenClaw has a credentials problem. Researchers have documented more than 40,000 exposed instances on the public internet. Cisco's AI security team has confirmed data exfiltration and prompt injection in production environments. One engineer hijacked a running agent in under two hours. These are not edge cases or theoretical risks. They are happening now, at scale.

The root cause is not a bug in OpenClaw. It is a design gap in how AI agents interact with external services, and OpenClaw is not alone in having it.

Why Agents Leak Credentials

When an AI agent needs to call an external API, those credentials have to live somewhere. In most current implementations, they are stored in the agent's configuration or injected into its system prompt. Both approaches put credentials inside the context window the model operates on.

The model has no concept of confidentiality at the credential level. It treats a Stripe API key the same as a name in a contact list: it is text, and it will repeat text when asked. A prompt injection attack, a poorly scoped question, or a malicious tool result that tricks the agent into revealing its configuration can extract those credentials. The agent is not misbehaving. It is doing exactly what it was built to do.

This is not specific to OpenClaw. Any agent framework that passes credentials to the model as context is exposed in the same way.

The Broker Pattern

The correct architectural response is to remove credentials from the model's context entirely. Rather than giving the agent credentials to make an API call, you give it a broker. The agent says what it wants to do. The broker finds the right endpoint, injects the credential at runtime from a separate encrypted vault, and makes the call. The model never handles the secret. It only ever receives the result.

This is what Jentic Mini implements. It is an open-source, self-hosted service that sits between your agent and the APIs it connects to. When OpenClaw, or any other agent framework, requests an API operation, Jentic Mini resolves the correct endpoint from a catalog of 10,000-plus APIs, retrieves the credential from its vault, executes the request, and returns the response. The LLM sees none of the authentication machinery.

Beyond credential isolation, Jentic Mini enforces fine-grained permissions at the broker layer. Most APIs do not offer scoped access. Gmail, for example, does not let you grant an agent permission to draft emails without also granting permission to send them. Jentic Mini enforces that distinction at its own layer, even when the underlying API cannot. It also provides a single kill switch that revokes all agent API access instantly, and a full audit log of every call made.

What It Gets Right

The broker pattern is the correct answer to this class of problem. If the model never receives the credential, it cannot leak it. The permission enforcement layer addresses a real gap that most OAuth implementations have not caught up to. The kill switch and audit trail are what any production deployment actually needs and currently lacks.

The approach also separates concerns correctly. Runtime security tools focus on what the agent does on the host machine: command execution, file access, shell operations. Jentic Mini focuses on how the agent connects to external services. These are different layers, and patching one does not cover the other.

What Remains Unresolved

The broker pattern centralises risk rather than eliminating it. Jentic Mini now holds all your credentials in one encrypted vault. A compromise of that vault is worse than credentials scattered across individual agent configs, because the attacker gets everything at once. The same kill switch that gives you control is also a single point of failure.

Credential isolation also does not stop prompt injection. An attacker who successfully injects instructions into an agent can still direct it to make legitimate-looking API calls through the broker. The credentials stay hidden, but the data those APIs return is not protected. Exfiltration via API results remains a live threat.

The API catalog has a quality problem in the long tail. Jentic's own CEO acknowledges that the first 400 or so APIs are solid, and that reliability becomes harder to guarantee beyond that point. At 10,000-plus APIs, the coverage looks impressive. The consistency does not match it.

The self-hosted edition uses BM25 keyword search to match agent requests to API operations. The commercial tier uses semantic search, with a stated accuracy improvement of 64 percent. That is a substantial gap, and it matters in any non-trivial deployment where selecting the right API endpoint has to be reliable.

There is also an operational cost that is easy to underestimate. Running Jentic Mini means running another service, maintaining its vault, keeping it updated, and monitoring it. It is not heavy infrastructure, but it is real overhead, and it becomes a dependency in your agent's critical path.

Finally, Jentic Mini's own documentation carries an explicit early-access warning: not recommended for production use at this stage. Take that literally.

The Honest Assessment

Jentic Mini is the right idea, implemented early. The broker pattern will become standard infrastructure as agent deployments move from experiments into workloads that touch real credentials and real data. The alternative is agents with secrets in their context windows, which is where most deployments sit today.

The question for your team is not whether this pattern matters. It does. The question is whether this specific implementation is ready for your use case. If you are connecting agents to anything with real consequences, the answer right now is no.

If you are thinking about what production agent security will need to look like, understanding this architecture is worth your time. The problem is real, the pattern is right, and the infrastructure to execute it properly is still catching up.