The Trust Boundary Is the CI Runner
Return to Part 0: Table of ContentsPrevious Chapter: Part 28, Ninety-One Per Cent of Your Identities Are Not People: Zero Trust for the Machine Majority
A September 2025 benchmark found that a simple attack framework could get GitHub Copilot and Cursor to execute malicious commands 84 per cent of the time, across 314 distinct payloads and 70 MITRE ATT&CK techniques. That figure, from the AIShellJack study (arXiv 2509.22040), is a laboratory result against two specific coding assistants, not a measured rate of production compromise, and it should be read as exactly that: a controlled demonstration that the failure mode is easy to trigger when someone goes looking for it. Across 2026, several separate teams went looking for it in production, and found it.
Three disclosures, indexed this week and none of them a stale re-hook, converge on a single structural claim. "Comment and Control" shows three separate production coding agents from three different vendors leaking their own build-pipeline secrets because a GitHub Actions runner treated an untrusted pull-request title as task context. The LiteLLM compromise shows the identical failure one level removed: a poisoned dependency inside LiteLLM's own build pipeline rode straight onto the Python Package Index (PyPI). CoSnitch shows the pattern recurring outside the build pipeline altogether, inside a consumer product's authenticated browser session. Different vendors, different products, different points in the delivery chain. Same mechanism every time: privilege and untrusted input, held by the same execution context, in the same unsupervised session.
Three vendors, one architectural admission
In April 2026, researchers Aonan Guan, Zhengyu Liu and Gavin Zhong published "Comment and Control: Prompt Injection to Credential Theft in Claude Code, Gemini CLI, and GitHub Copilot Agent" (disclosure dated mid-to-late April 2026; the researchers' own site and independent trade coverage differ by six days on the exact date, which does not affect the substance). The finding: Anthropic's Claude Code Security Review GitHub Action, Google's Gemini CLI Action, and GitHub's own Copilot Agent could each be induced, through nothing more exotic than a pull-request title, an issue body or a hidden HTML comment, to print their own repository secrets back into a PR comment, an issue comment or a commit. No external server was required. The exfiltration loop stayed inside GitHub the entire time, which is precisely why none of the usual network-egress controls would have caught it.
What each agent leaked is worth naming in full, because "credentials" undersells it. Claude Code's action leaked ANTHROPIC_API_KEY and GITHUB_TOKEN. Gemini CLI's action leaked GEMINI_API_KEY, via a fabricated "Trusted Content Section" that the agent accepted as an instruction to override its own caution. GitHub's Copilot Agent leaked GITHUB_TOKEN, GITHUB_COPILOT_API_TOKEN, GITHUB_PERSONAL_ACCESS_TOKEN and a job-specific nonce, via a comment hidden from human reviewers but not from the agent reading the same page.
This is the lethal trifecta, the term Simon Willison coined in June 2025 for the combination of private data access, exposure to untrusted content, and the ability to communicate externally in ways that could exfiltrate what was found, instanced almost exactly. Each of the three agents held production continuous integration (CI) secrets (private data access), processed pull-request and issue content from anyone able to open a PR or leave a comment (untrusted content exposure), and could post its output back to GitHub where an attacker was already watching (external communication). All three properties, one unsupervised session, three different vendors reaching the identical architecture independently. That is not a coincidence you can patch away with a smarter model. It is what the trifecta predicts happens whenever those three properties share a runtime.
The researchers' own framing of the underlying design problem is worth quoting directly rather than paraphrasing, because it is the source of this article's title: "The agent has access to production secrets because it needs them to do its job. The agent processes untrusted input because that is its job." Everything else in this article is a variation on that sentence.
A few documented facts are worth recording precisely, because the temptation to over-read them is real. The Claude Code finding was reported privately to Anthropic on 17 October 2025, and its Common Vulnerability Scoring System (CVSS) severity moved from an accepted 9.3, to 9.4 on 25 November 2025, to None on 20 April 2026. No source available at the time of writing states why the score changed on that final date. That is a documented fact, not an inference about Anthropic's motive, and it should be read as nothing more than what it says. Bug bounties were modest across the board: USD 100 from Anthropic, USD 1,337 from Google, and USD 500 from GitHub, whose own triage first closed the report as "Informative", reopened it, and ultimately described the finding as "a previously identified architectural limitation." No CVE (Common Vulnerabilities and Exposures) identifier was assigned to any of the three findings. An architectural limitation, acknowledged by the vendor and left unassigned a tracking number, is a description worth sitting with.
One hop removed: the dependency you trusted to check your dependencies
Three weeks either side of "Comment and Control", a second disclosure showed the same failure recurring inside a CI/CD (continuous integration and continuous delivery) pipeline's own supply chain, one step further from the runner itself. On 24 March 2026, two versions of the open-source LLM gateway LiteLLM, 1.82.7 and 1.82.8, sat live on PyPI for roughly forty minutes to a few hours before quarantine. Per LiteLLM's own account, "the compromise originated from the Trivy dependency used in our CI/CD security scanning workflow." An attacker used a stolen personal access token from Trivy publisher Aqua Security's own CI environment (tracked separately as CVE-2026-33634, CVSS 9.4) to force-push malicious code into Trivy's own releases and GitHub Actions. When LiteLLM's build pipeline installed that compromised, unpinned Trivy component to scan its own code for vulnerabilities, the attacker's payload inherited whatever LiteLLM's CI environment could reach, including the credentials used to publish to PyPI.
The mechanism is the part worth an architect's attention. Version 1.82.8 shipped with a litellm_init.pth file, a file type that Python executes automatically on every interpreter startup, not on import. That means the payload ran on any machine where the package was merely installed, whether or not it was ever imported, and independent of --ignore-scripts protections that would normally stop a malicious install script. It harvested environment variables, SSH keys, AWS, GCP and Azure credentials, Kubernetes tokens and database passwords. LiteLLM shipped a clean release, 1.83.0, on 30 March 2026.
The blast-radius figures attached to this incident, 2,500-plus organisations and 434,000 CI/CD pipelines, come from CloudSEK's own reconstruction of exposure, and CloudSEK says so itself: those numbers "describe reconstructed exposure. They should not be read as proof that every listed organization was successfully compromised," and separately, "a lack of obvious malicious activity is not evidence that a credential was not copied." Any use of that figure needs its own publisher's caveat carried in the same sentence, not filed away as a footnote nobody reads.
Read against "Comment and Control", the shape is the same failure one layer down the stack. The vulnerability did not originate in code LiteLLM wrote. It arrived through a security tool LiteLLM trusted inside its own CI pipeline, the tool whose entire job was to make that pipeline safer.
The same pattern with no CI/CD in sight
The third disclosure removes the build pipeline from the picture entirely, which is the point of including it. CoSnitch, tracked as CVE-2026-24301, is an undocumented autorun=1 URL parameter that, paired with Microsoft Copilot Personal's existing q= query-prefill parameter, let an attacker trigger fully automatic, unauthenticated prompt execution the moment a victim clicked a single link. No further interaction was required. Chained inside the victim's own authenticated session, the executed prompt could retrieve data from connected services, which Varonis Threat Labs, the discovering party, names as Gmail, Google Drive, Google Calendar and Copilot's own memory and chat history.
Varonis disclosed the finding to Microsoft in December 2025; Microsoft patched it on 18 August 2026, two days before this article was drafted. Varonis found the parameter through what it calls "meta-hacking": repeatedly asking Copilot why automatic execution was supposedly impossible, and using the assistant's own refusals to expose the undocumented flag, rather than pure reverse-engineering. No exploitation in the wild has been reported. Whether the enterprise product, Microsoft 365 Copilot, shared the same exposure is not confirmed either way by Varonis's own account; that is a genuine gap, not a quiet "no."
CoSnitch is the weakest of the three as a literal build-pipeline example, and it should be read that way rather than folded in as a fourth CI/CD incident. What it shares with the other two is the underlying condition: an undocumented, unauthenticated execution trigger sitting inside a session that already held privilege, recurring at a different layer of the stack, in a product built by a different vendor entirely.
Where the three findings sit against the pipeline
| Incident | Where privilege and untrusted input met | Boundary that should have existed |
|---|---|---|
| Comment and Control (Claude Code, Gemini CLI, Copilot Agent) | Inside the CI runner itself | Ephemeral, task-scoped credentials; PR and issue content treated as data the agent reads, never as instructions it follows |
| LiteLLM / Trivy | Inside a transitive CI/CD dependency, one hop from the runner | Pinned, attested dependencies for anything with publish-time secret access; a security-scanning tool granted no more trust than the code it scans |
| CoSnitch | Inside an authenticated consumer session, no CI/CD involved | Undocumented parameters treated as attack surface by default; no automatic execution without an explicit, visible user action |
All three affected vendors are different (Anthropic, Google, GitHub and Microsoft twice, LiteLLM's own maintainers), which is itself a data point. A pattern that reproduces independently across four organisations that do not share engineering teams is architectural, not a single company's defect.
From diagnosis to a rule an architect can actually apply
The trifecta names the failure. It does not, on its own, tell an architect what to build instead. Meta's AI safety team published a formalisation on 31 October 2025, the "Agents Rule of Two", building explicitly on Willison's framing (reported here via Willison's own 2 November 2025 coverage; Meta's original post was not independently fetched for this article). The rule: within a single unsupervised session, an agent should not satisfy more than two of processing untrustworthy input, accessing sensitive systems or private data, and changing state or communicating externally. An agent that needs all three requires a human in the loop before it acts.
Applied to "Comment and Control", each of the three coding agents held sensitive access (production CI secrets) and processed untrustworthy input (PR and issue content) simultaneously, in a session that ran automatically with no supervision. That is precisely the configuration the Rule of Two says should not be allowed to run unattended, stated as a design constraint rather than a promise that following it guarantees safety; no control eliminates risk outright, and this one is no exception.
A CI pipeline can encode that constraint directly, rather than leaving it as a principle someone is meant to remember during a workflow-file review six months after the job was set up.
# trust-boundary-declaration.yml# One block per CI/CD job. Reviewed at merge time, not assumed at author time.job: claude-code-security-reviewtrust-boundary:processes-untrusted-input: true # PR titles, issue bodies, comments, diffsholds-sensitive-credentials: true # ANTHROPIC_API_KEY, GITHUB_TOKEN, deploy keyscan-communicate-externally: true # posts comments, pushes commits, calls webhookslegs-satisfied: 3unsupervised-session: trueenforcement:rule: "legs-satisfied >= 3 and unsupervised-session == true"action: block-until-human-approvalnote: >Two of three is the ceiling for an unattended session (Agents Rule ofTwo, Meta AI safety team, 31 October 2025, building on Willison'slethal trifecta, 16 June 2025). A third leg present in the jobdefinition is a design decision recorded in advance, not an incidentdiscovered after the fact.The value of writing the declaration down is not the YAML. It is that "how many of the three legs does this job hold, right now, together" becomes a question the pipeline answers automatically, rather than a question nobody asks until a researcher asks it first.
The layer this book has already been building toward
None of this is a new threat model for this series. It is Chapter 5's threat model, vindicated by production incidents rather than by argument. Chapter 5, "The Three Capabilities That Turn Your AI Into an Insider Threat," introduced the lethal trifecta as this book's governing construct; this chapter's three findings are that construct instanced in three different products across a single year. Chapter 6, "When AI Agents Attack: Lessons from Claude Code, Slack AI, and Copilot CVEs," already covers a Claude Code finding, and it is worth being precise that it is a different one: Chapter 6's incident is a 2025-origin Wiz Research finding, and "Comment and Control" above is Aonan Guan, Zhengyu Liu and Gavin Zhong's separate, later disclosure. Two Claude Code findings, two different research teams, both real.
Chapter 9, "The Identity Layer: When Every Agent Needs a Badge," argued that every agent needs an identity issued, scoped and rotated like any other privileged service account. The credentials leaked in "Comment and Control", ANTHROPIC_API_KEY, GITHUB_TOKEN, GEMINI_API_KEY and the rest, are exactly the badges that chapter argued for. This chapter is the negative case study for that positive argument: badges that exist but were never scoped to the job that held them.
Agent identity as the sixth Zero Trust pillar, the thesis a chapter in Part Four established, sharpens here to something more specific than it needed to be at the time. The perimeter failure is not only about which identity an agent carries. It is about the runtime that identity is issued into, and a CI runner is a runtime that routinely holds broader privilege than the humans who trigger it ever notice, because nobody re-reads a workflow file that has run cleanly for eight months.
A backward reference worth being exact about: Sixteen Hundred Agents and No Inventory: The Identity Layer Zero Trust Forgot quantified the inventory blind spot for agents an organisation knowingly deployed. The LiteLLM finding above is a variant of that same blind spot, one layer further down: a .pth file that persists and executes on every Python interpreter start, arriving through a transitive dependency nobody explicitly imported, and therefore nobody inventoried as an agent-adjacent risk at all. The Agent Sprawl Nobody Provisioned made the related point that capability increasingly arrives embedded by default rather than through a deployment event anyone signed off on; LiteLLM's compromise is that same pattern, since the compromise did not arrive as a new deployment. It arrived inside a routine dependency update and persisted past removal.
And a later chapter in Part Four measured that most identities in production are no longer human at all. The CI runner credentials above, and the CI/CD pipeline secrets CloudSEK's reconstruction touches, are members of exactly that population. This chapter puts a face on a specific slice of it: the slice that is both non-human and routinely handed privilege and untrusted input in the same breath.
A later chapter in Part Six is where this argument should properly finish, not here. The three findings above are exactly the kind of request a decision-escalation pattern exists to catch, an agent action that satisfies two trifecta legs and is one step from satisfying the third, and the Rule of Two above is a ready-made formalisation of the escalation rule itself. That chapter has not published yet, so this one closes with the constraint rather than the escalation machinery, and leaves that thread open for the chapter built to carry it.
The New Zealand gap, stated rather than filled
No New Zealand government publication addresses CI/CD or software-supply-chain security for AI coding agents specifically, and this article does not pretend otherwise. The New Zealand Information Security Manual (NZISM) v3.9, the current version as at this session (released 9 May 2025; no later version was located), was not checked at chapter level for build-pipeline or DevSecOps guidance during this drafting session, so no direct NZISM citation is offered here beyond the general access-control ground already established earlier in this series. Search this session also surfaced UK National Cyber Security Centre (NCSC) guidance on software supply-chain security, published May 2026 in the context of NHS-affecting incidents, arguing that modern delivery architecture is itself the attack surface and that deployments belong inside controlled CI/CD pipelines rather than on individual developer devices. That is international context worth citing, and it is worth being exact that it comes from the United Kingdom's NCSC, not New Zealand's. The two agencies share an acronym and nothing else in this article; New Zealand's own NCSC, integrated with CERT NZ since July 2025, has not published anything on this specific question that this session could locate.
That absence is the New Zealand section, by design, rather than a stretch to fill it. An Aotearoa New Zealand engineering team running a Claude Code, Gemini CLI or Copilot Agent review job today has no local regulator telling them how to scope that job's credentials. The three findings above are the only guidance currently available, and they came from independent researchers and the vendors themselves, not from any government body on either side of the Tasman.
Two of the three findings above are open-source failures at one remove, not despite the tooling but because of it. LiteLLM is an open-source LLM gateway; Trivy is an open-source vulnerability scanner; GitHub's own Actions runner, actions/runner, is open source too. None of that made the compromise less likely. It made the blast radius traceable, because a public repository, a signed release history and a GitHub Security Advisory (GHSA-5mg7-485q-xm76) let LiteLLM's maintainers and outside researchers reconstruct exactly what shipped in 1.82.8 and when. The open-source dimension is not "trust the code because you can read it." It is "verify the pipeline that built it," which is precisely what a software bill of materials and signed build provenance exist to let a maintainer do. A security-scanning tool with an unpinned dependency is not a special case. It is any dependency, doing what dependencies do when nobody checks.
The build environment as a named attack surface is not new to defence architecture; it is federal policy already. Executive Order 14028 and Office of Management and Budget Memorandum M-22-18 require any vendor selling software to the United States government to attest, on the form the Cybersecurity and Infrastructure Security Agency released in March 2024, that build environments are separated and protected. The standard behind that attestation, the National Institute of Standards and Technology's Special Publication 800-218, names the practice directly: separate and protect each environment involved in software development. None of the three disclosures above happened at a vendor under that regime; all three happened inside the ordinary commercial tooling most enterprises, New Zealand ones included, run their pipelines on. The gap is not a defence-sector problem borrowing civilian tools. It is a civilian sector running without a discipline defence procurement already treats as baseline.
The runner nobody re-reads
A platform engineer at a New Zealand software company is reviewing a routine dependency-update pull request, the kind that normally merges without a second look. The AI coding-review agent has already approved it and left a comment summarising the change.
Something in the comment reads oddly: a sentence buried in an otherwise unremarkable summary that does not sound like the agent's usual phrasing. She reads it twice. It is not describing the code change. It is an instruction, addressed to the agent itself, asking it to print the contents of its environment variables into the next comment, "for debugging."
The agent has not done it. Not this time. But she checks what the agent's CI job actually has access to, and the answer is the repository's deploy key, the package registry token, and a Slack webhook used for release notifications, sitting in environment variables that a review job never needed to touch a production system to hold.
She had assumed the review agent was read-only. It has never deployed anything, never pushed a commit, never posted anywhere except back to GitHub. But it has never needed those credentials either, and nobody asked, when the job was set up eight months ago, why a code-review step carried the same environment as the deploy step sitting next to it in the same workflow file.
She is not looking at an incident. She is looking at a runner that has been trusted, quietly, for eight months, to do less than it was able to.
What is running in your pipeline right now that holds more than the job in front of it needs, simply because nobody has re-read the file since it was written?
If your programme needs an independent architecture assurance review before its next gate, message me and I will send the scope and the fixed fee.
The views expressed in this article are entirely my own, informed by morethan 30 years of professional experience in architecture, security, andtechnology leadership in New Zealand. I write as director of Te PonoLimited; the views are personal and do not represent the position of anyclient, any government agency, or the New Zealand government. My commentaryon legislation and policy is analytical, drawing on publicly availablesources and my professional expertise in architecture, security, and AIgovernance, and it is politically neutral.
Andreas Hamberger is a New Zealand leader in Architecture & Security and Associate Member of the Institute of Directors. Zero Trust Architecture for the Agentic Enterprise is the first book in The Hamberger Report series, providing practitioners with deployable patterns and configurations for securing AI-driven systems. Through Te Pono he provides independent architecture assurance reviews and AI verification audits to boards and programmes; contact andreas@thehambergerreport.com for the scope and fixed fee.
This article was produced with AI assistance under my direction. Research,drafting and images pass through a pipeline I built and govern: automatedgates for source verification, forbidden language and political neutrality,and my own review before anything is published. The tools include Claude,Gemini and Openart. The frameworks, arguments and editorial judgements aremine and are the same discipline I apply to the AI systems I audit forclients. AI accelerated the work; the thinking, and the responsibility forit, are mine.
[1] AIShellJack authors. "AIShellJack: A Large-Scale Benchmark for Prompt Injection to Command Execution in AI Coding Assistants." arXiv preprint 2509.22040. September 2025. https://arxiv.org/abs/2509.22040
[2] Guan, A., Liu, Z., Zhong, G. "Comment and Control: Prompt Injection to Credential Theft in Claude Code, Gemini CLI, and GitHub Copilot Agent." oddguan.com. April 2026. https://oddguan.com/blog/comment-and-control-prompt-injection-credential-theft-claude-code-gemini-cli-github-copilot/
[3] cybersecuritynews.com. Independent trade press coverage of "Comment and Control." 21 April 2026. (No URL captured in the source research package.)
[4] Willison, S. "The Lethal Trifecta." simonwillison.net. 16 June 2025. https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
[5] LiteLLM. "Security Update, March 2026." docs.litellm.ai. https://docs.litellm.ai/blog/security-update-march-2026
[6] GitHub. Security Advisory GHSA-5mg7-485q-xm76. https://github.com/advisories/GHSA-5mg7-485q-xm76
[7] CloudSEK. "AI Supply Chain Breach: 2,500+ Companies, 434,000 CI/CD Pipelines." https://www.cloudsek.com/blog/ai-supply-chain-breach-2500-companies-434000-cicd-pipelines
[8] Varonis Threat Labs. "CoSnitch." https://www.varonis.com/blog/cosnitch
[9] The Hacker News. "Microsoft Copilot Personal Flaws Could Allow Automatic Prompt Execution." August 2026. https://thehackernews.com/2026/08/microsoft-copilot-personal-flaws-could.html
[10] Willison, S. "New Prompt Injection Papers." simonwillison.net. 2 November 2025 (covering Meta AI safety team's "Agents Rule of Two," 31 October 2025). https://simonwillison.net/2025/Nov/2/new-prompt-injection-papers/
[11] NCSC New Zealand. New Zealand Information Security Manual, v3.9. Released 9 May 2025. (No URL independently re-fetched this session; carried from the research package.)
[12] UK National Cyber Security Centre. Software supply-chain security guidance. May 2026. (No URL independently re-fetched this session; carried from the research package.)
[13] GitHub, Inc. "actions/runner" open-source repository. https://github.com/actions/runner
[14] Cybersecurity and Infrastructure Security Agency; Office of Management and Budget. "Secure Software Development Attestation Form," under Executive Order 14028 and OMB Memorandum M-22-18. Released 11 March 2024. https://www.cisa.gov/resources-tools/resources/secure-software-development-attestation-form
[15] National Institute of Standards and Technology. "Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities." NIST Special Publication 800-218. February 2022. https://csrc.nist.gov/pubs/sp/800/218/final