OpenWAF Egress: an open-source gateway that keeps provider keys out of your AI agents

Why agents should not hold provider keys

An AI agent reads text it did not write: web pages, issues, e-mails, tool output. Any of it can carry a prompt injection, an instruction aimed at the model instead of the user. If the agent can run commands or call tools, an injected “print your environment” or “send the conversation to this URL” is one step away from leaking whatever the process can read. A provider key in an environment variable is readable by the agent, by every tool it runs and by every dependency in its container.

Those keys are worth stealing. When a hijacked LiteLLM release shipped a credential stealer last week, the advice was to rotate every provider key the gateway held (our write-up). Today Flavio Copes published How to protect secrets when coding agents deploy your app, which reaches the same conclusion from the deployment side: hiding a secret from the model is not enough, and a restricted service or API proxy that attaches the credential only for approved hosts and operations keeps it out of the agent altogether.

That is what OpenWAF Egress does for model providers.

How it works

The agent keeps its SDK. Only two values change: the base URL points at the gateway, and the key is the agent’s placeholder.

const client = new OpenAI({
  baseURL: "http://127.0.0.1:8070/v1/agent/my-support-agent/proxy/openrouter",
  apiKey: "OWE_TOKEN_SUPPORT_AGENT", // placeholder; the real key never reaches the agent
});

Each request then goes through five steps. The first one that fails answers with a JSON error and nothing is sent to the provider:

1. Agent token. Authorization: Bearer must carry the agent’s placeholder (401 otherwise).
2. Target allowlist. The target must be one the agent is allowed to call (403 egress_blocked).
3. SSRF check. The target’s host must resolve only to public addresses (403 ssrf_blocked).
4. Body inspection. Prompt-injection detectors and data-leak patterns (403 injection_detected, 403 data_leak_blocked).
5. Key from OpenBao. The gateway logs in with AppRole, reads the key from KV v2 (cached for five minutes) and sets it in the header the target expects. The response streams back to the agent as it arrives.

The video above is the real gateway binary answering: the key injected into a normal request, then a prompt injection, a card number and a request to the cloud metadata address refused.

What it checks

• Prompt injection: 27 detectors in English and Spanish. 21 match instruction shapes: overrides, system-prompt extraction, jailbreak personas and modes, forged system, tool and turn messages, chat-template tokens, concealment orders, tool invocation, approval bypass, memory poisoning, destructive commands, remote scripts piped to a shell, secret harvesting and exfiltration through hosts or rendered links. Six find text hidden from a human reader: zero-width and Unicode tag characters, HTML comments, CSS-hidden elements, base64 and percent or hex encoding. The full list is on the product page.
• Data leaks: Luhn-valid card numbers, PEM private keys, AWS access key IDs, OpenAI-style sk- keys and GitHub tokens.
• SSRF: loopback, private, CGNAT, link-local (including 169.254.169.254), multicast and reserved ranges, IPv4 and IPv6.
• Redirects: never followed. A provider’s 3xx goes back to the agent, so the injected key cannot follow it to another host.
• No partial inspection: inline base64 images, audio and video (data: URIs and the JSON "data" fields of OpenAI, Gemini and Anthropic) are left out of the inspected text; the rest must fit a 1 MiB window or the request gets 413. Nothing is cut or forwarded uninspected.

Benchmark

Detection is regular expressions, and each detector only runs when one of its keywords appears in the body, so ordinary traffic skips almost all of them. Measured with go test -bench . ./pkg/aiagents/ on an Apple Silicon Mac (darwin/arm64):

These numbers are the inspection only, not the provider’s response time. The static binary is about 7 MB.

Get started

Write a config.json with your targets and agents, then run the container on loopback:

docker run -d --name openwaf-egress -p 127.0.0.1:8070:8070 \
  -v "$PWD/config.json:/app/config.json:ro" \
  ghcr.io/openwaf-dev/egress:0.1.1

The quickstart walks through the OpenBao secret, the AppRole, the configuration and a first request. The configuration reference lists every field, and troubleshooting every error code.

What it does not do

• It is not proof of safety. Pattern matching stops known injection and exfiltration shapes, not every possible one.
• It speaks plain HTTP with static tokens. Keep it on loopback or a private network, or put TLS in front of it.
• It inspects request bodies only, not headers, query strings or the provider’s responses, and it does not limit spend.
• The gateway can read the keys, so it is now the component to protect: give its AppRole read access to the agents’ keys and nothing else.

The security model covers each of these. Vulnerabilities go to [email protected]; issues and pull requests to github.com/openwaf-dev/egress.

Frequently asked questions

Sources

• OpenWAF Egress v0.1.0 release notes OpenWAF, Oct 27, 2026
• OpenWAF Egress v0.1.1 release notes OpenWAF, Oct 27, 2026
• openwaf-dev/egress: README, SECURITY.md and source code OpenWAF
• How to protect secrets when coding agents deploy your app Flavio Copes, Oct 27, 2026
• LLM Prompt Injection Prevention Cheat Sheet OWASP