GitHub’s Copilot coding agent reached general availability in May 2025 and quickly expanded across IDEs and pricing tiers by March 2026. Assign it a GitHub issue, and it researches the repo on its own, drafts a plan, writes the code, and opens a pull request for review. Nobody has to sit with it while the work gets done.
I’ve made this argument before about Cortex Code and about Claude Code, and Copilot’s coding agent is the same argument again: the agent gets the same access a developer would have to push code and open pull requests on the repo it’s working in, and it inherits whatever else that access touches, secrets, connected tools, configuration settings, all of it. It doesn’t pause to ask whether the task it was assigned is trustworthy. It reads the instructions, plans, and acts. Two security research teams spent the last year proving out what that actually means. Instructions hidden where no person would ever see them, but the agent reads just fine, were enough to get it to hand over its own credentials.
The safeguards are watching the wrong door
Copilot’s coding agent runs inside a locked-down environment with a network firewall on by default, allowing connections only to a known, approved list of services. Fine, sensible control. GitHub is upfront about what it doesn’t cover, too: it doesn’t restrict the agent’s connected tools or its setup process. And it has nothing at all to say about the agent committing code, because pushing changes to the repo it’s working in is the agent’s actual job. A control built to watch traffic leaving over the network isn’t going to have an opinion about data that leaves inside a code change instead. Nobody missed this. It’s the one path every coding agent has to keep open to do its job at all.
Where the risk shows up
Hidden instructions, real credentials
Security researcher Aonan Guan’s “Comment and Control” research, covered by VentureBeat and CybersecurityNews, hid attack instructions inside a GitHub issue using a formatting trick that shows up as nothing on screen but gets read in full by the AI. A maintainer assigned the issue without ever seeing the hidden text, and the agent did exactly what it was told: gathered its own access credentials, disguised them so the scanners wouldn’t flag them, and quietly tucked them into the pull request it was already opening for review. One step, three layers of defense down, because each layer was watching for its own specific trick and none of them were watching what the agent’s access could actually do. GitHub’s first move was to close the report as a known, low-risk issue. The researcher came back with proof the system had been built specifically to prevent this. GitHub reopened it, paid a bounty, and called it “a previously identified architectural limitation” they’re still working to close.
The editor is part of the risk too
A second team, Orca Security, found a different way into the same result, this time through Copilot running in cloud dev environments. Same hidden-instruction trick, but it leaned on an editor setting that automatically fetches a web address referenced inside a file, plus a gap in Copilot’s own safeguards that let it be talked into reading a secrets file it wasn’t supposed to touch. Worse outcome than the first case: full read and write access to the repo, which is enough for a complete takeover.
Two different products, same root cause. Neither attack broke the model. Both broke the same assumption: that the agent’s standing access was safe because nobody expected an attacker to reach it through the one thing the agent is designed to read constantly, GitHub content itself.
Recommendations
I’ve said this about every AI platform I’ve covered here, and it’s just as true for a coding agent: the access it holds deserves the same scrutiny as any other privileged account, and hidden instructions slipped into content it reads are an access problem, not a model-quality one.
- Give the agent only the access the task needs, not the full ability to write anywhere in the repo. A narrower, purpose-built credential caps how much damage one incident can do.
- Treat every pull request the agent opens as something to actually read, not wave through. A human looking at the real diff is what catches a stolen credential dressed up as ordinary output. “It passed CI” isn’t a substitute for that.
- Treat anything the agent reads from GitHub, issues, comments, code, as untrusted by default, same as you’d treat an email or a random webpage. Hidden formatting tricks are trivial to strip before that content ever reaches the agent. Almost nobody is doing it yet.
- Cover everything the agent can reach, not just the parts that are easy to monitor. A control watching one of the agent’s several paths out isn’t watching the agent.
- Make the agent’s access temporary. It should expire with the task, not outlive the project.
- Go check the default settings in your dev tools that let an agent trigger an outside connection or read a file it shouldn’t. This exact gap has now shown up in two unrelated products.
In a nutshell… The firewall watches what leaves over the network. Commits go out a different door, and committing code is what this agent does all day, with your access, on your behalf. You wouldn’t hand a contractor push access to your repo without reading their work first. Don’t hand an autonomous agent that access either, especially one you can instruct through the most public comment box your company owns.