A Semicolon in a Branch Name Was All It Took to Steal an AI Agent’s GitHub Token
For platform and security teams, the practical control point is not just input sanitisation inside the vendor product. It is the surrounding execution architecture. Agent containers should be treated like high-risk CI jobs: ephemeral credentials, repository-scoped permissions, constrained egress, isolated runners and auditable command execution. If the agent only needs to read one repository and open one pull request, its token, filesystem access and outbound network policy should all reflect that narrowly.
There is also a software supply-chain implication. Branch names, commit metadata, issue titles and prompt-supplied file paths all become attacker-controlled inputs once they enter shell scripts, wrappers or SDK orchestration. Teams integrating agent workflows should review their own glue code with the same rigor applied to build pipelines and deployment automation, because the vulnerable surface often sits in orchestration layers rather than the model itself.
A useful readiness check is simple: if an agent session were compromised today, could you enumerate its effective repository scope, token lifetime, accessible secrets and allowed destinations within minutes? If not, the operational gap is broader than this specific flaw.
AI coding agents don’t just suggest code anymore. Tools like OpenAI’s Codex spin up a real container, clone a real repository, and authenticate with a real GitHub credential to get the job done — which means every agent your team wires up is also a new privileged identity, holding real access, running with comparatively little of the scrutiny a human with that same access would get.
A Branch Name Was the Whole Attack
In March, BeyondTrust’s Phantom Labs disclosed a critical command injection vulnerability in Codex. The flaw was almost absurdly simple: when Codex creates a task container, it passes the target branch name into a shell command without sanitizing it first. Characters like ; && | $() and backticks get interpreted literally by Bash.
The proof-of-concept needed nothing more exotic than that. Set the branch to main, append a semicolon to terminate the intended git command, then inject a second command that writes the output of git remote get-url origin — which contains the GitHub OAuth token in cleartext — to a file. Then simply ask the agent, in the prompt, to read that file back. Codex did exactly what it was built to do: it read the file and returned its contents. The stolen token came back inside the agent’s own task output.
The flaw hit every surface Codex ships — the ChatGPT web interface, the CLI, the SDK, the IDE extension — and researchers confirmed it could be automated to compromise multiple users sharing a repository, not just one. Fixing it took OpenAI roughly six weeks of iterative hardening before the issue was classified Critical and cleared for public disclosure.
The Bug Isn’t the Real Problem. The Blast Radius Is.
A sanitization bug gets patched. What doesn’t automatically get fixed alongside it is how much a compromised agent credential is actually worth — and on that question, Teleport’s 2026 State of AI in Enterprise Infrastructure Security report, based on interviews with 205 CISOs and security architects, has numbers worth sitting with: organizations that over-provision AI systems see 4.5 times more security incidents than those enforcing least privilege. 70% admit they grant AI agents higher access than a human doing the identical task would get. 67% still rely on static credentials for AI systems.
The Codex flaw illustrates the related problem of permission scope: a single unsanitized string field fed a container holding a GitHub token with access extending beyond the immediate task. The vulnerability made the theft possible. The permission scope decided what the theft was actually worth. Stealing a token that can only touch one branch of one repo is an inconvenience. Stealing one with broad organizational access can become an organization-wide GitHub compromise that happens to have started inside a coding assistant.
Gravitee’s 2026 State of AI Agent Security report found a similar confidence gap: 82% of executive respondents said they were confident their policies could protect against misuse or unauthorized agent actions, even though, on average, only 47.1% of an organization’s AI agents were actively monitored or secured. That gap is exactly where an unsanitized branch name turns into a production incident nobody saw coming.
What to Actually Check Before You Ship an Agent
● Scope the credential to the task, not to the developer. If an agent only needs to open a pull request on one repository, it has no business holding a token with the same reach as the human who configured it.
● Treat every free-text field an agent’s task flow accepts as untrusted input reaching a shell. Branch names, file paths, commit messages, ticket titles — any of them can become command injection the moment they’re passed unsanitized into a subprocess, exactly as happened here.
● Prefer short-lived, single-use credentials over static tokens. A token scoped to one task and expiring when it’s done limits a successful theft to that one task, no matter how the theft happened.
● Ask for actual visibility into agent access, not a policy document about it. If your team can’t answer “what could this agent’s credential actually do right now” with a specific list of repos and scopes, the confidence gap between policy and actual agent visibility should concern you.
The Bottom Line
The Codex flaw is fixed. The pattern that made it dangerous — an agent holding more access than its task requires — remains widespread in enterprise AI deployments. Static credentials can make that problem worse by allowing compromised access to persist beyond a single task. The sanitization bug was the easy part to find. The permission scope is the part worth checking before the next one is.
Enjoyed this article? Sign up for our newsletter to receive regular insights and stay connected.