An AI Agent Found a Live Admin Token in a 2023 Docker Image in 25 Minutes. Yours Is Probably Still There.
Strix, the open-source pentest agent, and the class of secret that scoped tokens will never reach
A GitHub token sat inside a public container image for three years and four months before anyone who wasn't supposed to have it went looking. When someone finally did, it took 25 minutes, no credentials, no source code, and no human deciding where to look. The someone was a machine.
The token belonged to basetenbot. It had admin and push rights on Baseten's main product repository, the GitOps repo that drives its clusters, and its Homebrew tap, plus read/write on private per-customer repos. Baseten is a $13 billion inference company that serious teams depend on. The credential was minted into a Docker build on March 3, 2023, and it still worked in July 2026.
That gap, three years of a live admin key sitting in a downloadable file, is the story. Not the breach. The dwell.
What Strix is, and why the how matters
Strix is an open-source autonomous penetration-testing agent from a company called OmniSecure, Apache-2.0 licensed, around 63,000 stars, at v1.6.2. You point it at a target, give it a Docker runtime and an LLM API key, and it runs the way a pentester runs: reconnaissance first, then follow whatever it finds. It ships a full offensive toolkit, an HTTP proxy, a browser, a shell, a Python sandbox for writing proof-of-concept exploits, and it validates findings by exploiting them rather than pattern-matching and hoping.
The Baseten writeup, published by Strix's Alex Schapiro on September 1 and back on the Hacker News front page on September 15, is worth reading as a trace, not a trophy. The chain is what makes it unsettling.
Strix enumerated subdomains and certificate logs and found a Harbor container registry at a Baseten address. One Harbor project was public: no token needed, so the agent listed the repositories, minted an anonymous pull token, and pulled an image called baseten/baseten-app. A lesser tool would have filed "exposed registry" and stopped. Strix instead asked the only question that matters, which is what the exposure is worth, and pulled the image apart to find out. First it found a pair of AWS keys, tried a read-only sts:GetCallerIdentity call, got InvalidClientTokenId, and moved on. Dead key, no false positive.
Then it ran TruffleHog over the layers and inspected the image config directly, and found the live one in a place most secret scanners that target the filesystem never look: the history[].created_by field of the image config. A build step had run RUN GITHUB_TOKEN=${GITHUB_TOKEN} ..., and Docker recorded the expanded command, token and all, into the image's metadata. Strix used the token for a read-only GET /user, got a 200 and the name basetenbot, checked the OAuth scopes, checked the per-repo permissions with read-only calls, confirmed admin: true, and stopped there. It did not clone the customer repo or push anything. It wrote the disclosure email.
Baseten's security team confirmed it critical and rotated the token by the next afternoon. They handled it well. The uncomfortable part is not Baseten's response. It is that the finding was sitting in public for 40 months and the thing that found it was an agent following its nose, not a person who knew where to dig.
Why this is the counter-signal to everything else that shipped this week
The same week Strix's writeup trended, Cloudflare shipped per-Worker access roles so an agent's API token can be scoped to one application, and Anthropic's Claude Code added request-class headers so a gateway can apply policy per call. Both are genuinely good. Both share a blind spot with every other scoped-credential feature: they govern tokens minted from now on.
The token that takes down your infrastructure was almost certainly minted years ago, with scopes nobody would grant today, and it lives somewhere nobody is scanning: a build argument recorded in image history, a CI log, an old layer in a registry project someone set public for a reason that stopped being true in 2023. Least-privilege for new credentials does nothing about the over-privileged ones already in circulation. And the asymmetry just flipped. Finding these used to require a bored expert with time. Now it requires an agent, a domain, and 25 minutes, and the agents are cheap and patient and don't need to know where to look.
That is the real shift Strix represents. Not that AI can pentest. That the cost of the reconnaissance half of an attack, the part that used to protect you through sheer tedium, has collapsed. Whoever runs the agent first wins, and there is no rule that it has to be you.
Put this into practice
The good news is that the specific mistake here is mechanical, and so is finding it. You do not need Strix to check your own images, though you can, and I will get to that.
Start with the build history, because that is where this token was and where filesystem scanners miss it. For any image you have published, or any base image you inherit from, run:
docker history --no-trunc <image>
and read the CREATED BY column for build steps that expanded a secret into a RUN line. The token in the Baseten image was not in a file you could rm. It was in the recorded command. If you want the raw config, docker inspect the image and read the history[].created_by entries, or pull the config blob and grep it.
Then check what your build tokens can actually do, not what you assume they do. A token that fetches a private dependency needs read access to that dependency. If the same token has admin on your product repo, a leak is catastrophic instead of annoying. Run a read-only permission check on every bot account and scope it down to the one thing it fetches.
Fix the pattern at the source. Docker's own documentation is explicit that build arguments and environment variables are the wrong place for secrets because they persist in image metadata and history. The right tool is a secret mount:
RUN --mount=type=secret,id=GIT_AUTH_TOKEN \
git config --global url."https://$(cat /run/secrets/GIT_AUTH_TOKEN)@github.com/".insteadOf "git@github.com:"
built with docker build --secret id=GIT_AUTH_TOKEN,env=GITHUB_TOKEN .. The secret is available during the step and never written into a layer or the history. Note the second half of the Baseten mistake too: git config --global writes the authenticated URL into the config file, so even a correctly mounted secret can leak if the command consuming it persists it. Change how the token arrives and check that the command using it does not save it.
And revoke the old tokens. This is the step people skip because it feels done once the Dockerfile is fixed. It is not. Rewriting the Dockerfile does nothing to the images already pulled and cached around the internet. The Baseten token kept working for three years after whatever build produced it; the fix that mattered was rotation, not a cleaner build.
If you want the adversary's-eye view, Strix is free to run locally: Docker, an LLM key, strix --target ./your-repo or a domain you own. Its own README carries the warning that matters, that you run it only against systems you own or have written permission to test, and that unauthorized testing is illegal in most places. Read that line as a real constraint, not boilerplate.
Where this breaks
Strix is not a magic wand, and treating it as one is its own risk. It needs Docker running and a paid LLM key (or a ChatGPT subscription sign-in) to do anything, so "free and open source" still has a per-run cost that scales with how thorough you let it be. A deep run burns tokens.
It is an autonomous agent pointed at live systems, which means the same capability that found Baseten's token can knock over a fragile staging environment if you aim it carelessly. The authorization warning is not there for lawyers. Point it only at what you own.
And an agent that follows its nose can also follow it into a ditch: chase a dead lead, over-report a benign registry, spend your budget mapping an attack surface that turns out to hold nothing. The Baseten run reads clean because it worked. The runs that find nothing still cost money and still need a human to read the output and decide what is real. Strix reduces the price of looking. It does not remove the person who decides what the looking meant.
The larger limitation is conceptual. Finding your own leaked token first is good. It does not mean no one else already found it, and it does not un-leak the ones that have been public for years. Rotation closes the specific door. It does not tell you who walked through it while it was open, and for a credential that was live for three years, that is not a comfortable unknown.
The move is yours
The headline is that an AI agent found an admin token in 25 minutes. The lesson is that the token was findable for three years and nobody was looking, because looking used to be expensive. It isn't anymore, for you or for anyone else.
You cannot fix the asymmetry, but you can be on the right side of it this week. Run docker history --no-trunc on your oldest public images. Scope your build tokens to what they fetch. Move secrets to mounts. Rotate the old ones as if they are already compromised, because you genuinely cannot prove they aren't. The agents are cheap now. Be the one who runs yours first.
Sources: Strix on GitHub, Strix / Baseten disclosure (September 1, 2026), Docker build variables docs, Docker build secrets docs.
Medium metadata
Title: An AI Agent Found a Live Admin Token in a 2023 Docker Image in 25 Minutes. Yours Is Probably Still There. Subtitle: Strix, the open-source pentest agent, and the class of secret that scoped tokens will never reach Tags: Cybersecurity, AI Agents, Docker, DevSecOps, Application Security Canonical: fervorai.dev (import to Medium from the published URL)