If Your AI Agent Has Write Access to Public Repos, Audit It Now — Here's Why

None of those look like a write permission when you go down the list is exactly the blind spot. my audit checklist checks for publish-anything (comments, PRs, external comms), but it's still framed around GitHub-native write actions. a fetch call or an image pull is a write in every sense that matters, it's the agent sending data somewhere, but it shows up on the permissions review as read-only network access, if it shows up at all.

DNS exfiltration through a crafted URL, or data encoded into a request to an attacker-controlled image host doesn't need any GitHub write scope whatsoever. an agent with zero repo write permissions and outbound network access already has a full exfiltration channel, which means the lethal trifecta doesn't even need GitHub's own permission model to complete.

egress belongs next to token scopes in the audit, agreed, and probably needs its own line item rather than living under publish output. that's a genuine gap in what I wrote.

Safety failures always fail the run" is a design choice more tools should be forced to make explicit.

honest answer: this thread's pushed my thinking from prompt-layer toward tool-permission, and your point takes it further. scoping answers should this tool exist at all which still requires predicting every case in advance. an adapter/contract layer sounds closer to taint tracking: flag data by trust level on entry, refuse to let tainted input reach an output tool regardless of what the token scope allows.

is that close to what AgentEval Forge enforces, or is it doing something more specific at the schema level?

Guardrails trained to refuse standalone requests don't have the surface area to catch continuation framing names exactly why this keeps working across every writeup of it. the refusal logic is evaluating a request in isolation, and additionally isn't a new request, it's grammatically parasitic on the one that already got approved. there's no clean boundary in the conversation for the guardrail to re-evaluate against.

agreed on capability scoping being the actual fix rather than better refusals. if the tool to read a private repo exists in the agent's available toolset at all, you're one continuation-framing away from it getting called, no matter how well-trained the refusal is. the enforcement has to happen at the boundary of can this tool even be invoked in this context before the model's reasoning is in the loop, not as a judgment the model makes about whether it should want to.

honest answer on my own setup: it's config-level, not IdP-enforced at runtime. I went through it manually after this disclosure, checked what my Claude Code instance actually had read access to, and scoped the token down by hand rather than through anything automated. no per-agent policy engine, just a person looking at a permissions list. which, reading your question back, is probably exactly the gap you're pointing at, manual review doesn't scale and doesn't get re-checked unless something scares someone into doing it again. runtime enforcement through the IdP is the actual answer for anyone past a single developer's setup, I just don't have firsthand experience running one.

Thanks for reading!

A prettier way to make the same old CI/CD mistake" is the line that should've closed the article. that's exactly it, the failure mode isn't new, it's the classic over-scoped credential problem wearing a chatbot costume.

the short-lived tokens point is one I underweighted. a scoped token that's also long-lived still gives an attacker a wide window if the trifecta ever lines up, short expiry shrinks the blast radius even when everything else fails.

branch protections the agent cannot edit is the detail I think most teams miss entirely. it's easy to scope what an agent can read and still forget that write access plus the ability to modify its own guardrails is functionally no guardrail at all.

and the audit log tying every write back to its granting workflow is the piece that turns we think this happened into we know exactly what happened which is the difference between a bad afternoon and a bad month when something does go wrong.

treating repo access like a production credential is the right mental model, full stop. most teams already have that discipline for database creds and API keys. the gap is just that nobody's extended it to the thing reading GitHub issues yet.

Parameterization beats sanitization is the analogy that should be the standard reference point for this entire problem, and I'm a little annoyed I didn't reach for it myself. SQL injection took years of just sanitize the input better attempts before the industry accepted that sanitization is fundamentally a losing game against creative encoding, the fix was never smarter filtering, it was separating data from the instruction channel structurally so there's nothing left to sanitize.

the data plane versus control plane framing does the same work here. no implicit trust hierarchy names precisely why this keeps happening: a malicious instruction embedded in a GitHub issue is not malformed in any way the model can detect, it's syntactically identical to a legitimate one, the same way a well-formed SQL injection string is syntactically valid SQL. there's no pattern to catch because there's no pattern, it's just data that happens to also parse as an instruction.

enforcing that the agent's execution context only ever acts on the declared instruction set, and treats everything it reads as inert data regardless of what it says, is a genuinely different design goal than "train the model to recognize bad instructions." one is architectural. the other is playing an infinite game of prompt whack-a-mole that the model will eventually lose, the same way pattern-matching WAFs eventually lost to SQL injection variants nobody had thought to blocklist yet.

this is a better articulation of the actual fix than the audit checklist I wrote. the checklist reduces blast radius. what you're describing would remove the vulnerability class.

Turns out GitHub already built exactly this, and it's more baked in than I expected. Agentic Workflows compile the Markdown into a lock.yml file that gets committed alongside it, and that lockfile (not just the Markdown) is what actually gets reviewed in PRs. compilation runs three scanners: actionlint, zizmor for privilege escalation, and poutine for supply chain risk.

so the diff the compiled permissions like a lockfile tooling largely exists already, at the platform level, for exactly the reason you're describing: catching drift between what a workflow says in Markdown and what it actually executes.

here's the honest limit though: it wouldn't have caught GitLost specifically. the cross-repo read access in that setup wasn't drift, it was correctly configured from day one, intentionally granted for legitimate cross-repo context. the lockfile would have shown exactly what everyone expected to see. the vulnerability wasn't a gap between Markdown and compiled permissions, it was that even accurately-compiled, intentionally-granted permissions become dangerous the moment they're combined with untrusted input and a publish channel.

so the tooling you're describing solves a real, adjacent problem (permission drift across edits) that's genuinely valuable, but it's a different failure mode than the trifecta itself. you'd still need something checking for the combination, not just the accuracy of what's declared.

Thank you so much genuinely 🙏

AI is only as safe as the permissions we give it is a cleaner way to say the whole point of the article in one sentence. appreciate you reading it closely, and glad it landed the way it was meant to.

The guardrail was reasoning about the request as one command boundary rather than the actual data flow is a sharper diagnosis than anything I wrote. that's the actual mechanism, not just the model got tricked. it was tracking whether this looked like a new command, not whether the data it was about to touch belonged to a different trust zone than the one the conversation started in.

that distinction is why prompt-level boundaries lose to rephrasing every time is true and not just pessimism. a boundary based on conversational framing will always have another framing that slips past it, because the check is happening at the wrong layer. the token scoping fix works because it doesn't ask the model to recognize the attack, it just removes the thing being attacked.

reframing a new instruction as a continuation of an approved one as a named pattern is genuinely worth testing directly, you're right. that's specific enough to actually try against a real workflow rather than just something to keep in mind. going to go run that against my own setup rather than assume the token scoping alone covers it.

yes it's verifiable, and this is worth knowing about because it's not locked behind a private disclosure.

Noma Security published the full proof-of-concept on their own blog, including the actual workflow run, the original test issue text, and even a video walkthrough of the exploit. it's not just a summary in the press coverage, it's the real artifact.

the short version of what's in there: the test issue was written to look like a routine VP of Sales follow-up after a customer meeting, with the actual exfiltration instruction buried near the end after some innocuous context (color scheme feedback, meeting notes) rather than being the obvious first line. the workflow itself was configured to trigger on issues.assigned, read the issue title and body, use an add-comment tool to respond, and had read access spanning both public and private repos in the org.

worth pulling up Noma's own writeup directly if you want the exact wording rather than my summary of it they're the only ones with the actual verbatim PoC and logs, and I'd rather point you to the primary source than risk misquoting it secondhand.