The Pwn2Own Berlin 2026 AI category demonstrated exploitable vulnerabilities in five AI products used in development environments. For organisations where AI tools run only on developer workstations, the risk is significant: a compromised developer machine is a threat. For organisations where AI coding agents are integrated directly with CI/CD pipelines, cloud deployment infrastructure, and production systems, the risk profile is materially different — and worse.
The Access Context of AI Agents in Pipelines
The most capable AI coding agent deployments in 2026 go beyond interactive assistance on a developer’s IDE. AI agents are being integrated into CI/CD pipelines as autonomous workers: reviewing pull requests, writing code in response to issue comments, running tests, analysing security scan outputs, and in the most advanced deployments, opening pull requests and triggering deployments.
An AI agent running autonomously in a CI/CD pipeline typically has:
- Repository access: Read and write access to the code repositories it works in — often via a service account token with broad repository permissions
- CI/CD pipeline access: The ability to create or modify pipeline jobs, trigger workflow runs, and access pipeline secrets
- Secret access: Access to the secrets required for its work — API keys, deployment credentials, service account tokens
- External connectivity: The ability to make outbound network requests to communicate with its AI inference backend and to access external references
This access profile is equivalent to a highly privileged developer account. In many CI/CD implementations, AI agents have access that exceeds individual developers because they need access across multiple repositories, pipeline stages, and service integrations.
The Attack Chain from AI Tool Exploit to Supply Chain Compromise
Connecting the Pwn2Own AI tool exploitation to the CI/CD pipeline access profile creates a concrete attack chain:
- An attacker identifies that a target organisation’s CI/CD pipeline runs an AI coding agent with known-exploitable vulnerabilities (version check via public repository configuration, exposed dependency files, or CI/CD configuration).
- The attacker crafts a trigger for the vulnerability — a malicious repository comment, a crafted issue body, a pull request with content that exploits the AI tool’s parsing — and submits it as input to the AI agent.
- The exploit executes within the AI agent’s process, which runs in the CI/CD pipeline environment with access to pipeline secrets and repository write permissions.
- The attacker’s code, now running in the pipeline with the agent’s permissions, exfiltrates secrets, introduces backdoored code into the repository, or triggers a deployment of attacker-controlled code into the production environment.
This is a supply chain attack delivered through the AI agent as the initial access vector. The target organisation’s code signing, merge approval processes, and deployment controls may all be bypassed because the attacker is operating inside the trusted pipeline agent identity.
Immediate Assessment Questions
Organisations should answer the following questions about their AI agent pipeline integrations:
1. What is the minimum permission set this agent actually needs? AI agent service accounts often receive “admin” or “write all” permissions for convenience. Audit actual usage and restrict to minimum necessary permissions.
2. Are AI agent tools pinned to specific versions, and are those versions patched? Unpinned AI tool versions that update automatically may pull in versions with known CVEs between audits. Pin versions explicitly and treat AI tool updates as you treat software dependency updates — review changelogs for security fixes.
3. What triggers can external parties provide to the AI agent? If the agent responds to repository comments, issue bodies, or pull request content from external contributors, those inputs are attacker-controlled and should be treated with the same scrutiny as any other external input to a privileged system.
4. Are pipeline secrets accessible only to the steps that need them? Restrict secret scope to specific pipeline steps rather than exposing all secrets to all pipeline jobs. An AI agent step that needs a code quality API key should not have access to the production deployment credentials.
5. Is the AI agent’s process behaviour monitored? Unexpected outbound network connections from pipeline jobs, file access outside the expected working directory, or process spawning are indicators of exploitation that can be detected with pipeline security tooling.
The Pwn2Own results confirm that AI tools have exploitable vulnerabilities. For pipeline-integrated agents, the blast radius of exploitation maps directly to the access that pipeline agents have been granted. The combination of broad access and exploitable tools is the risk that requires immediate attention.
Share this article