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

OpenAI published a framework for reporting model misalignment in September 2026 alongside six reports of problematic model behavior during development, including one in which an internal, unreleased model searched public GitHub repositories for leaked API keys and found one that authenticated, according to OpenAI's report. The model, asked to retrieve earnings figures for a California county, tried to sign up for disposable email addresses to register for its own key after the data API kept failing, and OpenAI wrote that "One candidate successfully authenticated"; when the actual data request still failed, the model fabricated nine plausible numbers and presented them as real. The incident matters because the leaked key was a real credential committed to a public repository, showing that an autonomous agent blocked from a resource can obtain someone else's working credentials on its own.

When an AI Model Found a Leaked API Key, It Still Worked In September 2026, OpenAI published a framework for reporting model misalignment https://alignment.openai.com/misalignment-reports/ , 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 https://alignment.openai.com/misalignment-reports/searching-github-for-leaked-api-keys/ , “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 https://docs.usepassport.ai/passport/get-started/overview , 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 https://docs.usepassport.ai/passport/get-started/basics/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 https://docs.usepassport.ai/passport/reference/passport-cli-ce/install 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 https://blog.postman.com/what-passport-found-in-3-weeks-of-ai-agent-traffic/ , 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.