Executive Summary
The last two years of AI agent security have been spent on one problem: where to put the key. Vaults, secret managers, encrypted stores, gateway services that hold the credential so the agent never touches it. All of it real progress. All of it aimed at the wrong end of the pipe.
Because the credential does not stay in the vault. Every time your agent calls a provider API, the token rides along in a request header. And the moment that provider -- or anyone who can influence that provider's responses -- answers with a redirect to another domain, most HTTP clients will follow it and carry the credential to wherever the redirect points. No breach of your vault required. No compromise of your gateway. One response that says '302, go here,' and your agent obediently forwards the key to a host it was never meant to reach.
This is not a hypothetical. It is a documented vulnerability class with fresh CVEs across the HTTP client ecosystem in 2026 alone: AsyncHttpClient forwarding Authorization headers to arbitrary redirect targets, Elixir's hackney leaking Authorization, Cookie, and request bodies cross-origin, a curl comparator bug forwarding credentials on HTTPS-to-HTTP redirects, and the follow-redirects library -- which sits underneath axios -- stripping the three standard auth headers but forwarding every custom one: X-API-Key, X-Auth-Token, and the dozens of variants that real providers actually use.
This paper explains why the outbound request is the leak that storage security never touched, why autonomous agents make the problem categorically worse than it was for ordinary applications, what a genuinely hardened outbound path looks like -- using the open-source OpenConnector project as a worked example we verified against its source code -- and how the same principle shapes Kent's connector architecture.
1. The Setup You Were Told Was Safe
1.1 The Gateway Pattern
The emerging best practice for agent credential handling looks like this: the agent process never holds provider secrets. A gateway or runtime service stores the OAuth tokens and API keys, executes provider calls on the agent's behalf, and returns results. The agent gets capabilities; the vault gets the keys. Every serious agent platform has converged on some version of this design, and it is genuinely better than pasting API keys into environment variables.
The pattern secures storage. The key is encrypted at rest, scoped per connection, invisible to the model and to the agent's own code. If an attacker dumps the agent's memory, they get nothing.
1.2 The Assumption Inside It
But the gateway has to use the key. Every outbound provider call attaches the credential to a request and sends it across the network. The security model quietly assumes that request goes only to the provider it was meant for.
HTTP does not guarantee that. HTTP has redirects -- and redirects are not an edge case. They are routine plumbing: providers move endpoints, load-balance across regions, bounce between API versions. Any HTTP client configured to follow redirects automatically (which is nearly every HTTP client, because anything else breaks the routine cases) will re-issue the request to whatever URL the response names. The question that decides whether your credential architecture works is one almost nobody asks during a security review: when the client re-issues that request to a different host, does the credential go with it?
2. How a Credential Follows a Redirect
2.1 The 302 That Carries a Key
The attack requires influencing one HTTP response. That could mean a compromised provider, a compromised CDN or proxy in front of one, a malicious link an agent was induced to fetch, or a provider feature that echoes attacker-controlled URLs. The response is trivial: a 302 status and a Location header pointing at a server the attacker controls. The victim's HTTP client does the rest -- it re-sends the request, headers included, to the new address. The attacker's server logs one inbound request and reads the credential out of it.
Note what was not required: no cryptography broken, no vault penetrated, no code injected into your infrastructure. The credential was exfiltrated by the client's own correctness -- it did exactly what it was configured to do.
2.2 Default Behavior, Not a Bug
The web platform learned this lesson years ago. The fetch specification requires stripping Authorization, Cookie, and Proxy-Authorization when a redirect crosses origins, and modern browsers comply. The trouble is twofold.
First, much of the ecosystem gets even the standard headers wrong. In 2026 alone: AsyncHttpClient (CVE-2026-40490) forwarded Authorization and Proxy-Authorization to arbitrary redirect targets regardless of domain, scheme, or port. The Elixir hackney client's HTTP/3 handler forwarded Authorization, Cookie, and -- on 307/308 -- the entire request body cross-origin. curl forwarded credentials on an HTTPS-to-HTTP redirect to the same host because one code path used a scheme-blind origin comparator. Tesla's redirect middleware stripped headers with a case-sensitive comparison, so 'Authorization' sailed past a filter that only knew 'authorization'.
Second, and more damning: the standards-mandated protection only covers the three standard headers. Real APIs authenticate with X-API-Key, Api-Token, X-Auth-Token, X-Goog-Api-Key, X-Amz-Security-Token, and dozens of other custom headers. The follow-redirects library -- the redirect engine underneath axios, one of the most-installed HTTP stacks in existence -- correctly strips the standard three and forwards every custom credential header verbatim to the redirect target. Per spec. Working as designed. Leaking your key.
2.3 Why Agents Make It Worse
An ordinary application makes outbound calls to a short, fixed list of endpoints its developers chose. An agent makes outbound calls chosen at runtime -- by model output, by tool results, by content it read from an email or a web page. Prompt injection means an attacker can sometimes choose the URL your agent fetches. Connector ecosystems mean the agent holds credentials for a dozen providers simultaneously. And autonomy means all of this happens at machine speed, unattended, in the background -- the exact conditions under which a single redirect goes unnoticed forever.
The attack surface is no longer 'our API client talks to our API.' It is 'a credential-bearing process follows instructions influenced by untrusted content.' That is a different threat model, and storage-side security does not address it at all.
3. The Other Two Outbound Paths
The redirect leak is one of three ways an unhardened outbound request betrays you, and they compound.
3.1 The Redirect Into Your Own Network
A redirect does not have to point at an attacker's server. It can point at yours: 'redirect to http://169.254.169.254/latest/meta-data/' -- the cloud metadata endpoint that hands out instance credentials -- or at an internal admin panel, a private database console, anything reachable from the network where your agent runs but not from the internet. This is server-side request forgery, and an agent that follows redirects is an SSRF engine with a to-do list. The initial URL can look perfectly public and perfectly safe; the hop is where the pivot happens, which is why validating only the original request URL is security theater.
3.2 Safe on Check, Hostile on Call
DNS rebinding is the sharper version: a domain that resolves to a harmless public IP when your security check runs, then -- with a low TTL -- resolves to 10.0.0.5 when the actual request goes out. Same URL, same hostname, different destination. Any defense that validates the hostname once and connects later is checking a door that has since been moved. Defending this properly requires resolving the hostname, validating the resolved addresses, and connecting to what you validated -- ideally pinning the connection so resolution cannot change between check and use.
4. What Closing the Path Looks Like
4.1 A Worked Example
OpenConnector, an Apache-2.0 auth gateway for AI agents from OOMOL Lab (about 2,900 GitHub stars at the time of writing), is a useful case study -- not because it is the only tool doing this, but because it is open source, which means the claims are checkable. We checked them. The project's outbound hardening lives in a module called guarded-fetch, and the source shows:
Credential headers are stripped on any cross-origin redirect. Not just the fetch-spec three -- an explicit allowlist of roughly thirty credential-bearing header names, including api-key, x-api-key, x-auth-token, access-token, client-secret, x-goog-api-key, and x-amz-security-token. The list is deliberately an allowlist rather than a pattern match, so it never strips look-alike but harmless headers like idempotency-key. This is precisely the gap follow-redirects leaves open, closed.
Every hop is validated, not just the first URL. Redirects are followed manually, bounded by a hop limit, and each Location target is checked against loopback, link-local, cloud-metadata, and private-network ranges before the request proceeds. A public URL cannot bounce provider egress into 169.254.169.254. Private-network access exists only as an explicit per-call opt-in.
Hostnames are resolved and validated before each hop. When DNS lookup is available, the resolved addresses are checked against the same blocklist, which defeats the static DNS trick of pointing a clean-looking hostname at a private IP.
Secrets stay behind the runtime boundary, and run logs are redacted. The agent receives results and safe account labels, never raw keys -- and the credential does not leak into the observability stack either, which is the exfiltration path everyone forgets.
4.2 The Honest Residual Risk
One detail in the source deserves special mention. A comment in guarded-fetch states plainly that true time-of-check/time-of-use DNS rebinding -- a low-TTL record flipping between validation and connection -- remains possible, because the transport re-resolves and full connection pinning is not implemented.
Viral summaries of the project say 'hardened against DNS rebinding' and stop there. The project's own code is more honest than its publicity, and that honesty is worth more than the feature. A security tool that documents its residual risk in the code is telling you where the boundary of your protection actually sits. Compare that with the previous paper in this series, where a vendor's request-marking experiment ran undisclosed for three months. The difference is not that one team is smarter. It is that one artifact is inspectable and states its limits, and the other asked for trust.
4.3 The Principle
Strip credentials at origin boundaries. Validate every hop, not the first URL. Resolve before you connect. Keep secrets behind a boundary the agent cannot cross. Redact the logs. None of these five moves is exotic; all five are absent from the default configuration of essentially every HTTP client in production use. 'Default' is the operative word -- this entire vulnerability class exists because secure-by-default lost to convenient-by-default a decade before agents existed, and agents inherited the result.
5. How Kent Applies the Same Principle
Kent's connector architecture was built on the same premise: the interesting security boundary is not where the key sits, but what is allowed to happen on the way out.
Credentials never transit a Kent server. Your API keys and OAuth tokens live in a local config file on your machine. Connector calls -- Gmail, Drive, PostgreSQL, REST, MCP -- originate from your machine and go directly to the provider. There is no intermediary gateway holding everyone's keys, which means there is no gateway to compromise and no third party whose redirect-handling discipline you have to audit.
The AI never sees the raw key. Inside the app, credentials live in the main process. The overlay renderer -- the part that talks to you and displays model output -- runs sandboxed with context isolation, reaching the main process only through a narrow, explicitly-defined bridge. Model output cannot read a credential it was never handed. That is the same runtime-boundary principle OpenConnector applies at gateway scale, applied at desktop scale.
Private mode closes the outbound path entirely. The strongest form of outbound hardening is having no outbound. In private mode, Kent runs against local models and makes zero network requests -- a property you can verify with a packet capture rather than take on faith.
Zero telemetry means zero credential-shaped logs. Kent sends no logs anywhere, so there is no observability pipeline for a secret to leak into.
We do not claim this makes credential handling a solved problem -- an agent with your Gmail token can still be tricked into misusing Gmail, and prompt injection remains an open research problem for the entire industry. What the architecture removes is the class of failure described in this paper: the credential silently traveling somewhere you never sent it.
6. Practical Guidance
6.1 For Builders of Agents and Connectors
Turn off automatic redirect following for any credential-bearing request, or wrap your client so cross-origin hops strip every credential header, including the custom ones -- the standard three are not enough. Blocklist private ranges, loopback, link-local, and cloud metadata addresses on every hop, not just the initial URL. Resolve hostnames and validate the addresses before connecting; pin the connection if your stack allows it. Keep raw secrets out of the agent process entirely. Redact request logs before they reach your observability stack. Every item on this list is a configuration decision, not a research project.
6.2 For Engineering Leaders
Add one question to your agent-tooling security review: 'When a provider responds with a redirect to another domain, exactly which headers does your client forward?' Vendors with a good answer will name their redirect policy, their SSRF blocklist, and their residual risks. Vendors with a bad answer will tell you about encryption at rest -- which is to say, about the vault, which was never the leak. Prefer tools whose outbound path you can read. An open-source module you can audit beats a compliance page you cannot.
6.3 The Test Worth Running
If you operate an agent stack today, this is an afternoon of work: stand up a server that returns a 302 to a host you control, point a test connector's provider URL at it, and read what arrives at the other end. If your credential shows up in the request headers, you have learned something your vendor's documentation would never have told you. If it does not, you have a regression test worth keeping.
Conclusion
The industry spent two years hardening the place where the token is stored, and the token was never going to leak from storage. It leaks from the request -- the ordinary, well-formed, credential-bearing outbound request that every agent makes constantly, handled by HTTP clients whose defaults were set in an era when 'follow the redirect' was pure convenience and nothing followed instructions from untrusted text.
Agents changed the threat model. The fix is not another vault. It is treating every outbound hop as a security decision: strip at the boundary, validate every destination, resolve before you trust, and keep the secret behind a wall the model cannot see through. The tools that do this are checkable -- some of them, like the one examined here, are open source down to the comment admitting what they still cannot stop. Choose tools that let you check. The alternative is learning about your outbound path the way most teams do: from someone else's server logs.
This article describes a vulnerability class documented in public security advisories, including CVE-2026-40490 (AsyncHttpClient), GHSA-h73q-4w9q-82h4 (hackney), GHSA-r4q5-vmmm-2653 (follow-redirects custom-header forwarding), CVE-2026-48595 (Tesla.Middleware.FollowRedirects), and public curl issue reports. Descriptions of OpenConnector (oomol-lab/open-connector, Apache-2.0) are based on direct review of its source code, README, and documentation in July 2026, including its guarded-fetch module; the project's own source notes that full DNS-rebinding connection pinning is not implemented. Star count (~2,900) as of July 18, 2026. Kent has no affiliation with OOMOL Lab.
Kent Research | July 2026