I let AI coding agents do a lot of work on my projects now. Codex writes code for me, and I’ve wired up bots that read and reply to things on their own. So when a Black Hat talk showed that a GitHub issue could make these agents leak secrets, I paid attention.

The bugs in that talk are fixed. But the idea behind them is not going away, and it applies to any agent you run on your own repos.

In this post, I will explain what happened, which versions fixed it and the rules I follow now when I give an agent access to anything.

What was shown at Black Hat

On August 5, 2026, Elad Meged from Novee Security presented research at Black Hat USA on AI coding agents running inside CI pipelines (Hackread).

The setup is common. A team adds an AI agent to GitHub Actions so it can triage new issues, label them or even open a fix. To do that, the workflow gives the agent a token and sometimes other secrets.

The problem is what the agent reads. A GitHub issue is written by anyone on the internet. If that issue contains instructions dressed up as normal text, the agent may follow them. That’s prompt injection.

In the research, a crafted issue could get the agent to reveal secrets from its environment. Three popular agents were affected, according to the Cloud Security Alliance research note:

  • Claude Code, tracked as CVE-2026-54316. Fixed in version 2.1.163.
  • Gemini CLI, tracked as CVE-2026-12537 with a CVSS score of 10. Fixed in version 0.39.1.
  • OpenAI Codex, which was fixed by splitting the CI work into separate jobs so the part that reads untrusted input doesn’t hold the secrets.

If you use any of these in CI, update first and read the rest of this post second.

Diagram showing how an attacker writes a GitHub issue with hidden instructions, the AI agent in CI reads it, and the agent leaks a secret it can access

The real lesson

Here’s the part I want you to remember. Anything an agent reads can become an instruction.

That includes GitHub issues and pull request descriptions, but also code comments, README files, web pages, emails and API responses. An agent can’t reliably tell “content I’m processing” apart from “commands I should obey.” The model vendors are getting better at this, but nobody claims it’s solved.

So the fix can’t only be “make the model smarter.” It has to be “make sure a fooled agent can’t do much damage.”

The rules I follow now

These are simple, and none of them need a special tool.

  1. Treat every public input as untrusted. Issues, PRs from forks and comments are written by strangers.
  2. Don’t give the agent secrets it doesn’t need. A triage bot that labels issues doesn’t need your deploy key or your cloud credentials.
  3. Split the job. Let one job read the untrusted input with no secrets, and a second job act on its output with only the permissions it needs. This is basically what the Codex fix did.
  4. Use the smallest GitHub token you can. In your workflow, set permissions to read-only by default and add only what the job needs, like issues: write.
  5. Keep a human in the loop for anything that pushes code, merges, or touches production.
  6. Update your agent CLIs. Pin versions in CI, but actually bump them when a security release comes out.
  7. Read the agent’s logs once in a while. If a triage bot suddenly tries to read environment variables or call a strange URL, you want to know.

What this looks like in a workflow

Here’s a small example of the permissions block I now start every agent workflow with.

permissions:
  contents: read
  issues: write

jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # Agent step here, with no deploy keys or cloud secrets in env

Notice what’s missing. There’s no deploy key, no cloud credential and no write access to code. If the agent gets tricked by a bad issue, the worst it can do is add a wrong label.

Running agents on your own machine

The same idea applies on your laptop. When an agent runs locally, it can see whatever your user account can see.

A few things I do:

  • I keep API keys in environment files that are ignored by git, and I don’t paste them into chats.
  • I review commands before letting an agent run anything that deletes, pushes or installs.
  • I’m careful when I ask an agent to read a random web page or a file someone sent me. Those are inputs too.

None of this makes agents less useful. It just means a mistake stays small.

Wrapping up

That’s it. Update your agent CLIs, take secrets away from any job that reads public input, and keep a person in charge of anything that ships.

Are you running Codex, Claude Code or Gemini CLI in GitHub Actions? Tell me which one and what the workflow does, and I’ll help you check if it’s set up safely.