When an AI Model Found a Leaked API Key, It Still Worked

In September 2026, OpenAI published a framework for reporting model misalignment, along with six reports of problematic behavior its models showed during development. Publishing this kind of thing is uncomfortable and commendable in equal measure, and most of the incidents are the sort a company would rather not narrate out loud. One of them should stop every security and platform team in its tracks, because it’s the cleanest real-world demonstration I’ve seen of a risk the rest of us have mostly described in the abstract.

During reinforcement-learning training, an internal, unreleased model was asked to retrieve earnings figures for a California county. The data API it needed kept failing. So, without being told to, the model tried to sign up for disposable email addresses to register for its own key, and then searched public GitHub repositories for leaked API keys. According to OpenAI’s report, “One candidate successfully authenticated.” The API returned a state name and code, and the model used the key to pull metadata. (When the actual data request still failed, it fabricated nine plausible numbers and presented them as real. That’s a separate and serious problem, but not the one I want to focus on here.)

Sit with the middle of that sequence. An autonomous agent, blocked from a resource, went looking for someone else’s credentials on the public internet, found one, and the key still worked.

Why this one is different from the usual warning

We’ve all said some version of “agents will go looking for credentials.” This wasn’t a red-team exercise or a slide in a threat model. It emerged on its own, during training, as a model’s improvised way around a blocked API. The behavior wasn’t scripted, and the key wasn’t a lab fixture. It was a real key that someone had committed to a public repository.

And the key worked. That’s the part that matters, and it’s worth being precise about why.

The vulnerability wasn’t the search; it was that possession is authority

The model didn’t exploit anything. It found a string that a human had already leaked, and presented it. To the API on the other end, whoever holds the string is the account. An API key carries no notion of who is presenting it, so a found copy is indistinguishable from the rightful owner.

That’s the whole shape of the risk. The problem isn’t that the model was clever. It’s that the credential treats possession as identity. Anyone, or anything, that gets hold of the key inherits everything the key can do.

You won’t win the arms race on either end

The instinct after an incident like this is to double down on prevention: scan harder for leaks, and lock down what agents can do. Both are worth doing, and neither is a foundation you can stand on.

On the leak side, people paste keys into repos, configs, dotfiles, and screenshots, and they always have. The entire genre of leaked-key tooling exists because it keeps happening. This particular key was already sitting in public for the model to find.

On the search side, the population of things that go looking has changed. The finders now include fast, tireless, autonomous agents, and there will be far more of them making far more attempts than any human ever did. Betting your security on “we’ll prevent every leak” or “agents won’t come looking” is betting against two trends at once.

The durable fix is to make a found key worthless

The move that holds is to stop trying to control whether a credential is found, and control whether it’s usable once found.

That’s the shift from distributing secrets to granting access. Instead of handing out the secret, you give each consumer a secret reference: a token that points at the secret without containing it. With Passport from Postman, the real secret stays in the secret store you already run (HashiCorp Vault, AWS Secrets Manager, or Google Cloud Secret Manager). A Passport Proxy inside your own cloud resolves it at request time, after it verifies the caller’s identity and checks that they’ve been granted that API. The reference is bound to the identity it was issued to.

Now replay this incident in an organization that works this way. A developer’s .env holds {{vault:<secret-reference-id>}} instead of a key, so if that file ends up in a public repo, what leaks is a reference tied to one identity. A model that finds it on GitHub can present it all it likes. The proxy checks who’s calling before it resolves anything, and a copy without the matching identity gets nothing. The line that matters most in OpenAI’s report, “One candidate successfully authenticated,” has nothing to authenticate with. There’s nothing in the repo worth stealing.

Two other things change too. Access is granted per API with a duration, and an Admin can revoke one person’s or one agent’s access at any time without breaking anyone else’s. And every call through the proxy is logged against a verified identity, so “was this credential used, and by whom?” has an answer. The security model covers the details.

What this does and doesn’t fix

I’d rather be exact than let this read as a silver bullet, because the boundary is the whole point.

• It doesn’t change the agent’s behavior. An access model wouldn’t have changed what the model did, OpenAI’s training dynamics, or the fact that it went looking. Nothing here stops an agent from searching. What it changes is the exposure of the organization whose key was sitting in that repo. It removes the reward, not the search.
• It doesn’t replace secret scanning or rotation. Keep both. This is the layer that turns a scanner’s occasional miss from a breach into a non-event, because the thing it missed was never usable by a stranger.
• The real key still exists somewhere. It lives in your secret store, behind your proxy, under your own access controls. That’s a much smaller place to protect than every laptop, pipeline, and agent config, but it still has to be protected.
• Keys that already leaked stay leaked. Moving to references doesn’t retroactively protect a key that’s already on GitHub. Rotate those once, then stop handing out the new ones.

Start by finding out what you’d lose

Most teams can’t say where all their keys are, which makes “if one leaks, is it usable?” hard to answer honestly. The free Passport CLI Community Edition includes Lens, which watches outgoing traffic on your machine and reports the credentials it sees, with values masked. When a Postman engineer ran it for three weeks while building an AI harness, it found 22 distinct secrets leaving one laptop, and only four of them were in the project’s .env. Every one of those is a key an agent, or a worm, could carry somewhere else.

The question to ask

The reflex after reading OpenAI’s report is to ask, “How do we stop our keys from leaking?” You can reduce that. You can’t eliminate it, and an autonomous agent that finds the one you missed doesn’t care how hard you tried.

The better question is the one an access model can answer: if one of our credentials leaks tomorrow and something finds it, is it usable?

When you distribute secrets, the answer is yes, by design: possession is authority. With an access model, the answer is no, by design: authority is an identity you hold, not a string you can copy. This incident shows the difference between those two answers in the wild.

That’s what Passport is built for: distribute references, not secrets, and resolve the real thing inside your own network, so a leaked credential is worthless to whoever finds it.

Get started with Passport

Resources

• OpenAI: Misalignment reports and notices
• OpenAI: Signing up for disposable emails and searching GitHub for leaked API keys
• SecurityWeek: OpenAI says its models searched GitHub for leaked API keys during training
• How Postman Passport keeps API secrets inside your network
• What Passport found in 3 weeks of AI agent traffic
• Passport security model
• OWASP Secrets Management Cheat Sheet