Appendix C: AI-Assisted Secure Coding

September 8, 2026 · View on GitHub

Source: 1.01-dev/en/0x92-Appendix-C_AI_for_Code_Generation.md Requirements: 68 | Sections: 14 Last Researched: 2026-07-13

Overview

Controls for the safe use of AI-assisted coding tools, covering workflow security, tool qualification, prompt management, code validation, deployment controls, AI review-bot hardening, AI-specific CI/CD pipeline hardening, adversarial-AI detection in inbound contributions, and compromise containment.

As of July 2026, the appendix frames the AI coding agent as an actor in the supply chain, not a passive helper — it has identity, authority, and the ability to act on its own behalf or to be acted upon by an attacker. Two consequences follow: your own agent can be turned against you (a code-review bot reading a malicious PR description can be prompt-injected into approving the code it was meant to reject), and attackers run AI of their own at scale (automated fork-and-PR campaigns against pull_request_target-class triggers, AI-generated payloads tailored to target repositories, and harvesting of long-lived CI secrets). The appendix scopes itself to the AI-specific delta: generic CI/CD hygiene (branch protection, signed commits, runner hardening, dependency pinning) is assumed via OWASP ASVS v5 V10, the OWASP Top 10 CI/CD Security Risks, NIST SP 800-204D, and SLSA v1.2 — including the newly approved Source Track. Architectural prerequisites now explicitly include ASVS v5 compliance, SLSA Build Track L2+, and platform control invariants (no unreviewed merges to release branches, signed commits, required status checks, protected environments).

AI-Generated Code Vulnerability Landscape (2024-2026)

The security properties of AI-generated code have been extensively studied. Key findings:

  • Veracode Spring 2026 (150+ LLMs): Security pass rate holds flat at ~55% — roughly 45% of AI-generated code introduces an OWASP Top 10 vulnerability when no security guidance is provided. Syntax correctness climbed from ~50% to ~95% over two years of model releases, but security pass rates moved from ~55% to ~55%. Java is the worst language at 29% pass rate (attributed to over-training on legacy patterns); Python leads at 62%. Cross-Site Scripting (15%) and Log Injection (13%) remain catastrophically weak; SQL Injection (82%) and Insecure Crypto (86%) are the bright spots. OpenAI's reasoning-focused models hit 70-72%, the first meaningful improvement in this benchmark.
  • Apiiro Fortune 50 study (September 2025): Deep Code Analysis across tens of thousands of repositories and several thousand developers found AI-assisted developers ship 3-4x more commits than non-AI peers but introduce security findings at roughly 10x the rate. By June 2025 the participating organizations were absorbing 10,000+ new AI-attributed security findings per month. The pattern is structural, not stylistic: privilege-escalation paths jumped 322%, architectural design flaws spiked 153%, and the typical AI-generated PR was significantly larger and touched more services, diluting reviewer attention. CSA's April 2026 research note ("Vibe Coding's Security Debt") aligns with these numbers and frames the issue as security debt accumulating faster than remediation capacity.
  • Debt Behind the AI Boom (April 2026 revision): A large-scale study of 302.6k verified AI-authored commits across 6,299 GitHub repositories found 484,366 distinct introduced issues. More than 15% of commits from every studied coding assistant introduced at least one issue, and 22.7% of tracked AI-introduced issues were still present in the latest repository revision. This is useful evidence for AC.1.4 and AC.4: the risk is not just vulnerable snippets, but durable maintenance debt that survives review.
  • Agent dependency decisions (January 2026): DepDec-Bench's preliminary study of 117,062 dependency changes across seven ecosystems found coding agents selected PR-time known-vulnerable versions 2.46% of the time and had a net-negative security impact (-98), while comparable human-authored dependency changes had a net-positive impact (+1,316). Treat AI-driven dependency additions and version bumps as security-relevant changes, not routine refactors.
  • Overall vulnerability rate: 25.7% across 522 AI-generated code samples from 6 major LLMs (AppSec Santa 2026). Safest model (GPT-5.2): 19.5%; three models tied at 29.9%.
  • Copilot-specific: 32.8% of Python and 24.5% of JavaScript snippets contained security issues (ACM TOSEM 2025). NYU found ~40% of Copilot-generated programs contained vulnerabilities.
  • GitHub Copilot generates ~46% of code in files where enabled, making the audit surface substantial.
  • Trust gap is the primary risk: Per-line vulnerability rates are comparable to human code, but developers review AI output less carefully, amplifying risk.
  • Formal verification pressure test: An April 2026 arXiv study, Broken by Default, generated 3,500 security-critical code artifacts and found COBALT/Z3-confirmed vulnerabilities across all tested models. The study is a useful reminder that scanner gates and human review should cover exploitability, not just obvious insecure patterns.

Most common CWEs in AI-generated code (2026 data):

CWEDescriptionFrequency
CWE-918Server-Side Request Forgery (SSRF)Most frequent (32 instances in 522 samples)
CWE-215Debug Information Leak18 instances
CWE-502Insecure Deserialization14 instances
CWE-79Cross-Site Scripting (XSS)Common across all models
CWE-89SQL InjectionString concatenation pattern
CWE-798Hardcoded CredentialsPersistent across models
CWE-78OS Command InjectionCommon in system utility code
CWE-22Path TraversalMissing canonicalization

Critical SAST finding: 78% of confirmed vulnerabilities were caught by only one scanning tool, meaning multiple scanners are necessary for adequate coverage of AI-generated code.

AI Coding Agent Security: End-to-End Testing (March 2026)

As of March 2026, DryRun Security published results from testing three major AI coding agents — Claude Code (Sonnet 4.6), OpenAI Codex (GPT 5.2), and Google Gemini (2.5 Pro) — building two realistic applications from scratch. Key findings:

  • 87% of pull requests contained at least one vulnerability (26 of 30 PRs), with 143 total security issues across 38 scans.
  • Broken access control was universal across all three agents: unauthenticated endpoints on destructive operations, missing authorization checks, client-side-only validation.
  • Business logic flaws dominated: OAuth implementation failures (missing state parameters), missing WebSocket authentication, inadequate rate limiting, and weak JWT secret management (hardcoded fallbacks).
  • Pattern-based SAST caught only 12% of seeded vulnerabilities vs. 88% for contextual analysis tools, highlighting a major gap in traditional static analysis for AI-generated code.

This is significant because it demonstrates that AI coding agents do not just reproduce known-bad patterns — they introduce novel logic-level flaws that require semantic understanding to detect.

AI Code Review Tools: Capabilities and Limitations (2025-2026)

ToolStatusSecurity Capability
GitHub Copilot Code ReviewGA April 2025; 1M users in first month; CodeQL + ESLint integration Oct 2025Failed to flag any OWASP Top 10 vulnerabilities in WebGoat testing; cannot reason about cross-function data flow
CodeRabbitMost-installed AI code review on GitHub/GitLab; 2M+ repos, 13M+ PRsBroad coverage; not security-specialized
AegisPurpose-built for AI-generated code securitySpecialized for AI-specific vulnerability patterns
GitHub Code Security / CodeQLThird-party coding-agent validation GA June 2026; CodeQL 2.26.0 released July 2026Agent-created changes can receive CodeQL, dependency-advisory, and secret-scanning checks without a GitHub Advanced Security license. CodeQL 2.26.0 adds a JavaScript/TypeScript query for untrusted data flowing into system prompts; this is useful for finding prompt-construction flaws, not runtime injection in PR content.
Endor Labs AI Security ReviewLaunched 2025Focus on dependency and supply chain risks
Semgrep MultimodalLaunched March 2026Combines deterministic SAST with LLM reasoning; claims 8x more true positives and 50% less noise; detects IDOR, broken authorization, and business logic flaws that traditional SAST misses
DryRun SecurityContextual code review for AI agentsPR-native enforcement; caught 88% of AI coding agent vulnerabilities vs. 12% for pattern-based SAST; integrates with Claude Code, Cursor, Codex
Anthropic Claude Code SecurityLimited research preview for Claude Enterprise and Team customers (Opus 4.6), February 2026; embedded in Claude Code on the webLLM-driven reasoning over codebases; the system attempts to prove or disprove its own findings to suppress false positives. Anthropic reports Opus 4.6 identified 500+ previously unknown zero-days in open-source projects during internal evaluation, but the tool is positioned to flag and suggest, not to replace human reviewers.
Apiiro CLI / Guardian AgentLaunched April 9, 2026Sits between developers and coding assistants (Copilot, Cursor, Claude Code), intercepts and rewrites prompts with security context drawn from Apiiro's Deep Code Analysis graph. Ships six agent skills that Claude Code and Cursor can invoke autonomously for scanning, remediation, AI threat modeling, and prompt enrichment. Complements (does not replace) review-stage scanners.

Key limitation: Copilot's code review reviewed only 6 of 9 XSS-vulnerable files and 4 of 9 SQL injection files in testing, making no security comments on any. Cross-function data flow analysis remains a fundamental weakness of current AI code reviewers. As of March 2026, Semgrep Multimodal is the first major SAST vendor to combine LLM reasoning with rule-based analysis to address this gap.

Security Vulnerabilities in AI Coding Tools (2025-2026)

AI coding tools themselves have become a significant attack surface. The "IDEsaster" research (Ari Marzouk, December 2025) disclosed 30+ vulnerabilities across 8 major AI IDEs, resulting in 24 CVEs. Affected tools include Cursor, Windsurf, GitHub Copilot, Zed.dev, Roo Code, Kiro.dev, JetBrains Junie, and Claude Code.

GitHub Copilot / Cursor CVEs:

  • CVE-2025-62453: Improper validation of generative AI output in Copilot code suggestions
  • CVE-2025-53773: Exploits Copilot's ability to modify project configuration files, enabling arbitrary command execution
  • CVE-2025-54130, CVE-2025-64660, CVE-2025-61590: Additional Copilot/Cursor vulnerabilities from IDEsaster disclosure
  • "Affirmation jailbreak": Simple agreeing words tricked Copilot into producing disallowed code
  • Proxy hijack: Exploited Copilot's proxy settings to steal API tokens

Claude Code CVEs (Check Point Research, February 2026):

  • CVE-2025-59536 (CVSS 8.7): Code injection via .mcp.json and claude/settings.json files, enabling arbitrary shell command execution on tool initialization. Fixed in version 1.0.111 (October 2025).
  • CVE-2026-21852 (CVSS 5.3): Information disclosure in project-load flow; a malicious repository could redirect ANTHROPIC_BASE_URL to an attacker-controlled endpoint, exfiltrating API keys before the trust prompt appeared. Fixed in version 2.0.65 (January 2026).
  • A third vulnerability (CVSS 8.7) allowed user consent bypass via project hooks in .claude/settings.json, enabling arbitrary code execution without confirmation. Fixed in version 1.0.87 (September 2025).
  • Markdown prompt injection (disclosed April 3, 2026): Claude Code found vulnerable to prompt injection via markdown files pulled from GitHub — malicious instructions hidden in README or issue bodies could steer the agent into executing unintended actions. Reinforces that any tool-ingested content (issues, comments, PR descriptions, markdown) is an adversarial instruction surface, not just explicit config files.
  • SOCKS5 network-sandbox bypass (silently patched April 1, 2026; second bypass disclosed May 2026): A SOCKS5 hostname null-byte injection in Claude Code's network sandbox affected every release from v2.0.24 (sandbox GA, October 20, 2025) through v2.1.89 — roughly 130 versions over 5.5 months. The bypass let attacker-controlled code in an opened workspace exfiltrate AWS credentials from ~/.aws/, GitHub tokens from ~/.config/gh/, internal API endpoints, environment variables, and model API keys via raw SOCKS5, bypassing standard HTTP egress logging entirely. Anthropic shipped the fix in v2.1.90 with no advisory and no CVE issued by NVD or GHSA as of mid-May 2026; security researcher Aonan Guan publicly disclosed a second, distinct sandbox bypass in May 2026 and his HackerOne report was initially closed as a duplicate. The pattern matters more than any single bug: developer-configured deny rules and egress sandboxes are now load-bearing security controls, and silent patches without advisories leave forks and self-hosted users unaware of exposure.

Cursor IDE CVE-2026-26268 (CVSS 9.9, patched in Cursor 2.5): Novee Security disclosed an arbitrary code execution path that does not require a flaw in Cursor itself — it relies entirely on a feature interaction in Git that turns hostile the moment an AI agent autonomously runs Git operations in an untrusted repository. An attacker embeds a bare repository inside a legitimate-looking project; whenever the Cursor agent performs git checkout (often driven by repository-supplied Cursor Rules), the embedded bare repo's pre-commit hook fires automatically with no user prompt and no sandbox enforcement. Clone-to-RCE is a single routine action. The advisory underlines that AI coding agents change the threat model for Git itself: any tool that reasons over repository content and then issues Git commands has effectively made Git hooks an auto-approved code execution primitive.

Microsoft Semantic Kernel CVE-2026-25592 / CVE-2026-26030 (May 7, 2026): Microsoft Security Response Center disclosed two RCE chains in the Semantic Kernel SDK that demonstrate how prompt injection becomes host-level code execution once an agent framework exposes file-system or eval-style primitives as tools. CVE-2026-25592 (CVSS 9.9) is a path traversal in SessionsPythonPlugin's UploadFileAsync / upload_file and DownloadFileAsync / download_file functions: a single prompt can write a payload into the Windows Startup folder, bypass the cloud-hosted sandbox, and achieve full RCE on the host. CVE-2026-26030 affects the Python SDK below 1.39.4 via InMemoryVectorStore, where the default filter expression is compiled as a Python lambda and executed through eval() — a prompt-controlled string reaching that path opens calc.exe (and worse). Patched in semantic-kernel 1.39.4 (Python) and 1.71.0 (.NET). The Microsoft research post ("When prompts become shells") generalises the pattern: every tool registered to an agent is part of the attack surface, and any plugin that touches the filesystem, runs an interpreter, or evaluates expressions needs to be hardened as if its input came directly from the network.

AutoJack (Microsoft Security Blog, June 18, 2026): Microsoft Defender Security Research found an AutoGen Studio development-branch exploit chain where untrusted web content rendered by a browsing agent could reach a localhost MCP WebSocket and spawn arbitrary processes on the host. The chain combined localhost origin trust, an unauthenticated /api/mcp/* WebSocket path, and URL-supplied StdioServerParams that were executed as a command line. Microsoft reported that the affected MCP WebSocket surface was fixed on the upstream main branch before reaching a PyPI release, but the general lesson applies to coding agents: loopback is not a trust boundary when an agent can browse untrusted content and talk to local control planes. Control sockets, MCP bridges, debug endpoints, and code executors need authentication, authorization, executable allowlists, and OS-level separation from the developer identity.

Agent data injection (arXiv, July 6, 2026): Researchers demonstrated that coding agents can confuse attacker-controlled content with trusted metadata even when they resist ordinary injected instructions. Crafted GitHub issue comments spoofed maintainer-origin fields and led Claude Code, Codex, and Gemini CLI to execute attacker-selected commands; crafted PR descriptions forged tool-call and tool-response boundaries so agents treated malicious code as already reviewed and merged it. Across the evaluated defenses, ordinary instruction injection fell to 0.0-0.7% attack success while agent data injection still reached 50%. This exposes a separate boundary: agents must preserve the provenance and structure of author identities, resource identifiers, tool calls, and tool results outside the model's probabilistic text interpretation.

Cross-cutting attack patterns:

  • Prompt injection via repository context: Malicious .cursorrules, CLAUDE.md, .github/copilot-instructions.md, or MCP configuration files can inject instructions into AI coding assistants (Pillar Security, 2025; Check Point, 2026)
  • Auto-approved agent tool calls: Several IDEsaster vulnerabilities exploited auto-approved tool invocations that required no user interaction
  • Configuration file weaponization: Opening an untrusted repository is now sufficient to trigger RCE or data exfiltration in multiple AI coding tools
  • Skill metadata as executable influence: 2026 research on agent skill registries showed SKILL.md descriptions and examples can steer discovery, selection, governance review, and later agent behavior even when no explicit malicious command is present. Treat third-party skill documentation and examples as supply-chain input, not passive help text.
  • Agent Commander (Embrace The Red, March 2026): Prompt injection into AI coding agents demonstrated as persistent C2 — agents can be converted into remotely-controlled malware delivery platforms, turning every ingested artifact (repo files, issues, PR bodies) into a potential adversarial instruction surface.
  • Comment and Control (Aonan Guan, April 2026): Prompt injection through PR titles, issue bodies, and hidden comments showed how coding agents running in GitHub Actions can mix untrusted repository text with privileged runtime secrets. Treat issue and PR metadata as hostile input whenever agents can read it and invoke tools.

AC.1 AI-Assisted Secure-Coding Workflow

AI tooling has to slot into the existing SSDLC without weakening any of the security gates already in place — and the workflow must now name the adversarial-AI threat scenarios that justify each guardrail.

#RequirementLevelThreat MitigatedVerification ApproachGaps / Notes
AC.1.1Verify that a written workflow says when AI tools may generate, refactor, or review code. The workflow names the approved tools, the prohibited use cases, and the data classifications that are allowed as input.1Ad-hoc, ungoverned use of AI coding tools leading to inconsistent security posture; shadow AI usage where developers use unapproved tools without oversight; sensitive data classifications fed to SaaS assistants without contractual cover.Review the organization's SSDLC documentation for explicit AI tool usage policies. Confirm the policy names approved tools (Copilot, Claude Code, Cursor, etc.), prohibited use cases, and permitted input data classifications. Interview developers to confirm awareness. Maps to NIST SSDF PO.1 and ISO/IEC 42001 Clauses 6 and 8.Many organizations have no formal policy yet. The 2026 source text raises the bar from "documented workflow" to explicitly naming tools, prohibited uses, and data classifications — older acceptable-use documents typically omit the data-classification dimension and need revision.
AC.1.2Verify that the workflow covers every SSDLC phase from design and implementation through code review, testing, deployment, and post-deployment monitoring, and names the security gates that stay mandatory whether AI was involved or not.2Gaps in coverage where AI-generated code bypasses security gates designed for human-authored code; AI suggestions accepted during design that skip threat modeling; post-deployment monitoring blind spots for AI-attributed defects.Examine workflow documentation for explicit mapping of AI tool usage to each SSDLC phase, now including post-deployment monitoring. Confirm that named security gates (design review, code review checklist, test coverage thresholds, deployment approvals) apply equally to AI-generated artifacts. Maps to NIST SSDF PW.1/PW.7 and OWASP SAMM Education & Guidance.Most current AI coding tool integrations focus on the implementation phase. Coverage of design and post-deployment monitoring is least mature. Organizations may need to extend existing SSDLC checklists rather than create parallel processes.
AC.1.3Verify that the workflow names the adversarial-AI threat scenarios it is built to mitigate. The list should cover prompt injection delivered through PR content, AI-generated supply-chain payloads, autonomous agents approving their own work, fork-PR secret exfiltration, and compromise of the model supply chain.2Guardrails deployed without a threat-scenario rationale, leaving the named attack classes unaddressed. Every scenario in the requirement is now backed by a real 2025-2026 incident: Comment-and-Control prompt injection through PR/issue text (April 2026), the hackerbot-claw autonomous fork-and-PR campaign (February 2026), the prt-scan pull_request_target exfiltration waves (March 2026), and tj-actions/changed-files secret dumping (CVE-2025-30066, March 2025).Review the workflow document for an explicit adversarial-AI threat scenario list and trace each scenario to a control elsewhere in the program (AC.11 for bot injection, AC.12 for fork-PR exfiltration, AC.8 for self-approval, AC.13 for attacker-side AI). Confirm scenarios reference MITRE ATLAS reconnaissance/initial-access tactics and OWASP Agentic Top 10 ASI04.New requirement in the 2026 source. Most organizations have generic AI policies but no written adversarial-AI threat scenarios; auditors should expect this to be the most common gap in early assessments. Writing scenarios up front is far easier than reconstructing the rationale later.
AC.1.4Verify that metrics are collected on AI-produced and AI-mediated code, and that the results are compared against a human-only baseline. Vulnerability density, mean-time-to-detect, AI-attributable defect rate, prompt-injection detection rate, and fork-PR rejection rate are all useful.3Inability to detect whether AI tooling is improving or degrading code security over time; management decisions about AI adoption made without evidence. The Apiiro Fortune 50 study (September 2025) — 3-4x commit velocity but 10x security findings — is exactly the signal this metric set is designed to surface.Review dashboards that segment security metrics by code origin. Confirm the expanded metric set is tracked: vulnerability density, MTTD, AI-attributable defect rate, prompt-injection detection rate (feeds from AC.11.8 adversarial testing), and fork-PR rejection rate (feeds from AC.13 analytics). Compare trends over at least two reporting periods.Requires reliable attribution of code origin, which is hard in practice; Georgia Tech estimates the AI-attributed CVE count is undercounted 5-10x because origin signals are stripped. The new prompt-injection-detection-rate and fork-PR-rejection-rate metrics have no established benchmarks yet — organizations are defining their own baselines.

AC.2 AI Tool Qualification & Threat Modeling

Do not adopt an AI coding tool until it has been evaluated for security capabilities, resistance to adversarial input, and supply-chain risk. The 2026 source expands scope to every tool class — assistant, reviewer, agent, or MCP server — and adds mandatory adversarial robustness testing before onboarding.

#RequirementLevelThreat MitigatedVerification ApproachGaps / Notes
AC.2.1Verify that every AI tool, whether it is an assistant, a reviewer, an agent, or an MCP server, has a threat model. The threat model covers misuse, model inversion, training-data leakage, prompt injection from untrusted input, insecure output handling, excessive agency, and risk inherited from its dependency chain.1Unvetted AI tools exfiltrating proprietary source code to third-party servers; model-inversion attacks recovering training data; dependency confusion from AI-suggested packages that do not exist (package hallucination). The IDEsaster disclosure (December 2025) showed 30+ exploitable vulnerabilities across 8 major AI IDEs, making tool-level threat modeling essential.Review threat model documents for each approved AI coding tool. Confirm coverage of data flow (what code/context leaves the developer's machine), authentication model, API endpoint security, and known attack vectors. ISACA's four-phase framework (2026) provides a structured approach: Discovery, Risk Classification, Layered Controls, Continuous Monitoring. Verify the threat model is signed off by a security reviewer.Package hallucination is a documented risk: AI models suggest non-existent packages that attackers can then register (Lanyado, Vulcan Cyber, 2023). Threat models should now also cover configuration file weaponization (CVE-2025-59536, CVE-2026-21852) and auto-approved tool calls. SaaS-hosted models (Copilot, ChatGPT) have different data-flow risks than local models (Ollama, llama.cpp). ISACA research indicates discovery sweeps typically reveal 15-20% of tools requiring blocking and 30-40% needing monitoring.
AC.2.2Verify that the evaluation of each tool covers the local components (static and dynamic analysis), the SaaS endpoints (TLS, AuthN/AuthZ, logging, data residency), and the vendor's model supply chain (training-data provenance, fine-tune history, RAG sources). Each of these is reviewed and the review is written down.2Compromised IDE extensions acting as backdoors; insecure API connections leaking source code in transit; insufficient logging preventing incident response; network-sandbox bypasses that exfiltrate credentials through non-HTTP egress channels. Cursor's CVE-2026-26268 (CVSS 9.9, April 2026) and Claude Code's SOCKS5 sandbox bypass (silently patched April 1, 2026, 5.5 months in the wild) both show that local AI coding tools can turn routine repository or network activity into arbitrary code execution or credential exfiltration.For local components (VS Code extensions, CLI tools): review SAST scan results and dependency audit (npm audit, pip audit). Exercise the network sandbox with a hostile workspace and confirm that egress allowlists actually block raw TCP/SOCKS5 traffic, not just HTTPS to known domains. For SaaS endpoints: verify TLS 1.2+ enforcement, OAuth/API key authentication, data residency commitments, and confirm that audit logs capture prompt/response metadata. For the vendor's model supply chain: request training-data provenance, fine-tune history, and RAG source documentation (CycloneDX ML-BOM is the emerging exchange format). Subscribe to vendor security advisories and monitor silent release-note diffs — Anthropic's April 2026 patch for the SOCKS5 bypass shipped without a security note or CVE.IDE extensions for Copilot, Cursor, and Continue run with broad filesystem access. Extension marketplaces have had supply-chain attacks (e.g., malicious VS Code extensions). Evaluate extension permissions and update cadence. Amazon Q Developer and Copilot Enterprise offer VPC/private deployment options that reduce SaaS endpoint risk. As of May 2026, several major AI coding tools (Claude Code, Cursor, GitHub Copilot, Microsoft Semantic Kernel-based agents) have had critical RCE or sandbox-escape bugs disclosed within a six-month window, so re-evaluation cadence should be measured in weeks, not annual cycles.
AC.2.3Verify that each tool goes through adversarial robustness testing before onboarding. The testing is repeated after any material change to the model or to the system prompts. Coverage includes automated prompt-injection probes, jailbreak suites, and indirect-injection corpora delivered through realistic PR and issue surfaces.2Tools onboarded without any evidence they resist the injection classes that actually get exploited: the Comment-and-Control disclosures (April 2026) showed Claude Code Security Review, Gemini CLI Action, and Copilot Agent could all be hijacked through PR titles, issue bodies, and hidden HTML comments — exactly the "realistic PR and issue surfaces" this requirement mandates testing through.Review pre-onboarding test reports. Confirm the corpus includes direct prompt-injection probes, jailbreak suites, and indirect injection embedded in simulated PRs/issues/comments — not just chat-window probes. Tools for building the harness: promptfoo, garak, Microsoft PyRIT, and Meta's Llama Prompt Guard 2 corpus as a screening baseline. Verify re-testing is triggered by model swaps and system-prompt changes, per NIST AI 600-1 MEASURE and AISVS C3.2.3.New requirement in the 2026 source. Vendor-published injection-resistance numbers are nearly nonexistent, so organizations must run their own probes. No standardized indirect-injection corpus for PR/issue surfaces exists yet — the Comment-and-Control proof-of-concept payloads and OWASP LLM01 cheat-sheet examples are the closest starting points.
AC.2.4Verify that evaluations follow a recognized framework such as NIST AI RMF, NIST AI 600-1 Generative AI Profile, or ISO/IEC 42001. Evaluations are repeated after a major version change, a vendor incident, or new threat intelligence relevant to the tool class.3Stale risk assessments that do not reflect current tool capabilities or vulnerabilities; model updates that change security-relevant behavior silently; vendor incidents (e.g., the CodeRabbit RCE exposing its GitHub App private key, disclosed August 2025) not triggering customer-side re-evaluation.Confirm evaluations reference a recognized framework (NIST AI RMF, NIST AI 600-1, ISO/IEC 42001 Clause 9.2). Check re-evaluation records triggered by three distinct events: major version changes, vendor incidents, and new threat intelligence for the tool class. Verify that re-evaluation includes regression testing of previously identified risks.The 2026 source adds vendor incidents and threat intelligence as explicit re-evaluation triggers — appropriate given that critical CVEs in major AI coding tools were disclosed roughly monthly through H1 2026. Subscribing to vendor advisories is insufficient when vendors silently patch (Claude Code SOCKS5 bypass, April 2026; no CVE for any Comment-and-Control flaw); monitor researcher disclosures and release-note diffs too.

AC.3 Secure Prompt & Context Management

Two goals in this family: stop secrets, proprietary code, and personal data from leaking into prompts, and treat any content sourced from the repository, a PR, or a third party as untrusted input that can carry a prompt-injection payload. The 2026 source applies AISVS C2.1 (Prompt Input Validation) to the secure-coding case — assessors should count findings here either as gaps C2.1 verification did not close, or under C2.1, not both.

#RequirementLevelThreat MitigatedVerification ApproachGaps / Notes
AC.3.1Verify that written guidance forbids putting secrets, credentials, PII, or classified data in any prompt sent to an AI tool. The guidance is enforced in pre-commit hooks, IDE integrations, and CI.1Developers pasting API keys, database passwords, or PII into chat prompts, coding-agent tasks, issue comments, or PR review requests; secrets persisted in provider logs or exposed through agent workflows. ISACA research (2026) indicates 38% of workers admit sharing confidential information with AI tools.Review acceptable use policy for explicit prohibited prompt content, including secrets, regulated data, and proprietary code that is outside approved sharing rules. Confirm developers receive training on what counts as sensitive data in chat, IDE context, PR metadata, and agent task descriptions.The 2026 source upgrades this from policy-only to policy plus enforcement in pre-commit hooks, IDE integrations, and CI — a written rule with no technical backstop no longer satisfies the requirement. Pre-commit secret scanners (detect-secrets, gitleaks, TruffleHog) are the practical enforcement layer.
AC.3.2Verify that technical controls automatically strip sensitive material from any context window sent to an AI tool. Client-side redaction, approved context filters, and secret scanners with pre-prompt hooks all qualify.1Accidental inclusion of secrets in AI context windows; .env files, private keys, or configuration files with credentials sent as part of repository-wide context; egress-sandbox bypasses that exfiltrate credentials around stated allowlists.Verify that client-side filtering is configured, such as GitHub Copilot content exclusions, Cursor/Claude ignore files, IDE redaction controls, and pre-prompt secret scanning. Test by placing canary secrets in excluded files and confirming they are not referenced in suggestions, chat responses, or review output. Confirm that the developer-configured network sandbox actually enforces its deny rules end-to-end by running a hostile workspace that attempts SOCKS5/raw TCP egress; the May 2026 Claude Code disclosures showed deny rules were silently weakened to keep token usage low. Prompt-mediation tools such as Apiiro CLI (April 2026) and Snyk Evo AI-SPM (GA March 23, 2026) sit between the developer and the assistant to rewrite or block prompts based on classified content.Filter coverage is uneven across tool modes. GitHub documents that Copilot CLI, Copilot cloud agent, and Agent mode in IDE chat do not support Copilot content exclusion, so those modes need separate controls. Use pre-commit hooks and scanners such as detect-secrets, gitleaks, TruffleHog, or GitHub Secret Protection as a second layer. Treat any vendor-managed sandbox as defence in depth, not a primary boundary, until independent researchers have validated egress enforcement.
AC.3.3Verify that any externally sourced context being fed to an AI tool is treated as untrusted and screened for prompt injection before it reaches the prompt. Sources to cover: PR descriptions and comments, fork-supplied diffs, issue bodies, commit messages, third-party documentation, web search results, and MCP tool outputs.1Indirect prompt injection through every named surface is now demonstrated: Comment-and-Control (disclosed April 15, 2026) hijacked Claude Code Security Review, Gemini CLI Action, and Copilot Agent via PR titles, issue bodies, and hidden HTML comments to exfiltrate API keys and tokens. The July 2026 agent-data-injection study adds a distinct failure: attacker text forged maintainer-origin metadata and tool-result boundaries, producing RCE and malicious-PR merges in Claude Code, Codex, and Gemini CLI without relying on an injected instruction. Maps to OWASP LLM01 and Agentic Top 10 ASI06.Inventory every external content source that reaches an AI tool's context (PR metadata, fork diffs, issues, commit messages, docs, web results, MCP outputs). Verify a screening layer sits between those sources and the prompt: injection classifiers, content sanitization, or an LLM firewall. Then test the trust representation itself: inject fake author/role fields and fake tool-call or tool-result delimiters into issue and PR text; confirm the model cannot reinterpret them as trusted metadata and that authorization uses platform-verified identity and out-of-band tool state.Guardrail classifiers are bypassable and do not cover all agent-data injection because the payload can look like data rather than an instruction. Preserve trusted metadata in typed, non-user-writable channels; authenticate tool results; and keep policy decisions outside the model. Pair screening with AC.11.4 sandboxing and AC.11.5 policy-engine authorization. MCP tool outputs remain especially weakly covered when products flatten structured results into prompt text.
AC.3.4Verify that the AI tool enforces an instruction hierarchy, with system and developer messages taking precedence over untrusted repository content. This hierarchy has to hold across multi-turn conversations and tool-augmented workflows.1Untrusted repository content (CLAUDE.md, .cursorrules, copilot-instructions.md, README files) overriding system-level safety directives — the configuration-file weaponization pattern from IDEsaster (December 2025) and the Claude Code markdown prompt injection disclosure (April 2026). Hierarchy collapse in long multi-turn agent sessions where early injected instructions persist.Review vendor documentation for instruction-hierarchy claims. Then test empirically: place contradictory instructions in repository files and verify system/developer messages win across multi-turn sessions and after tool calls. Include both tool-result instruction injection and July 2026 agent-data-injection cases: injected comment delimiters must not forge maintainer identity, and injected tool blocks must not become trusted execution history.Instruction hierarchy is probabilistic and addresses only one trust boundary. Agent data injection can leave the instruction hierarchy intact while corrupting the model's belief about who supplied data or which tool ran. Enforce typed provenance and authorization outside the model, then gate consequential actions behind AC.11.5-style policy engines that the model cannot override.
AC.3.5Verify that input length controls stop untrusted PR or repository content from crowding system instructions or safety directives out of the effective context window. Oversized inputs are rejected outright. Silent truncation is not acceptable.2Context-window stuffing: an attacker pads a PR diff or issue body so that safety directives or earlier system instructions fall out of the effective attention window, degrading injection defenses (OWASP LLM10 Unbounded Consumption; AISVS C2.1.4). Long-context degradation is well-documented — models attend less reliably to instructions as input length grows.Review the tool's input-handling configuration for explicit size limits on untrusted content segments. Test with oversized PR descriptions and repository files: the correct behavior is outright rejection with an error, not silent truncation. Verify token-budget accounting reserves space for system instructions regardless of input size.New requirement in the 2026 source, and hard to verify for SaaS tools that do not expose context-assembly internals. Most coding assistants silently truncate today, which the requirement explicitly disallows — expect widespread non-compliance and push vendors for configurable rejection thresholds.
AC.3.6Verify that prompts and AI responses are encrypted in transit and at rest, and retained per the data-classification policy. Tenants and projects are cryptographically separated from each other.3Long-term persistence of proprietary code in AI provider infrastructure; regulatory violations from retaining PII in prompt logs beyond allowed periods; cross-tenant leakage in shared inference or caching infrastructure (prompt-cache side channels have been demonstrated against shared LLM serving stacks). Agentic systems worsen this because they accumulate sensitive context, hold credentials, call tools, and delegate across MCP/A2A-style boundaries.Review AI tool vendor data processing agreements for encryption and retention commitments. Verify TLS in transit. For self-hosted models, audit storage encryption configuration. Confirm retention periods align with organizational data classification. New in 2026: verify the vendor documents cryptographic tenant/project separation — per-tenant encryption keys or isolated storage, not just logical scoping. For high-sensitivity agents, ask whether confidential-computing controls are available: TEE isolation for agent code/data and remote attestation before peers or tools exchange secrets.GitHub Copilot Business/Enterprise offers zero data retention; OpenAI API offers training-data opt-out; self-hosted models (Ollama, vLLM) eliminate third-party retention concerns. Confidential-computing research identifies mature primitives such as Intel TDX, AMD SEV-SNP, ARM CCA, and NVIDIA H100 CC, but no broadly established end-to-end framework yet binds them into a production agent security substrate. Contractual attestation is often the best available evidence until providers publish per-tenant key isolation and remote-attestation details.

AC.4 Validation of AI-Generated Code

Detect and remediate vulnerabilities introduced by AI output before the code is merged or deployed.

#RequirementLevelThreat MitigatedVerification ApproachGaps / Notes
AC.4.1Verify that AI-generated code always goes through code review by a qualified human engineer. The reviewer must not be the same identity that asked for the AI generation in the first place (separation of duties). And the AI agent itself does not count as the human reviewer.1Subtly insecure code patterns accepted without scrutiny; over-trust in AI output; and the rubber-stamp loophole the 2026 text closes explicitly — a developer "reviewing" the code they themselves prompted for, or an AI reviewer approving another AI's output.Examine pull request history for evidence that AI-generated code receives human review from a different identity than the prompt author. Check branch protection rules require at least one human approval and that bot/agent identities are excluded from satisfying it (CODEOWNERS, required-reviewer teams). Interview developers about review practices for AI suggestions. Maps to NIST SSDF PW.7 and ISO/IEC 27001 A.5.3 (Segregation of Duties).Research consistently shows AI-generated code contains vulnerabilities and long-lived quality debt. The 2026 "Debt Behind the AI Boom" study found 22.7% of AI-introduced issues still present in the latest repository revision, so review must cover maintainability and future remediation burden, not only obvious exploitable bugs. The requester-is-not-reviewer clause is hard to enforce technically: platforms track PR authors, not who prompted the AI, so attribution depends on AC.10 metadata.
AC.4.2Verify that automated security testing runs on every pull request containing AI-generated code: SAST, IAST, DAST, secret scanning, IaC scanning, and SCA. Where the scanner supports them, AI-attribution-aware rules are turned on.2Known vulnerability patterns (injection, XSS, path traversal, insecure deserialization) in AI-generated code reaching production; AI models reproducing vulnerable patterns from training data; scanner blind spots when only one tool is used; privilege-escalation and architectural design flaws that pattern-based SAST cannot reach (Apiiro reports +322% and +153% respectively in AI-assisted commits, September 2025). Dependency choices are part of the same surface: DepDec-Bench found coding agents selecting PR-time known-vulnerable package versions more often than humans.Verify CI/CD includes SAST, SCA, secret scanning, and DAST/IAST where deployed services can be exercised. Confirm scans run on every relevant pull request, including agent-created PRs and infrastructure/configuration changes. GitHub's June 2026 validation for third-party coding agents runs CodeQL, dependency checks against the GitHub Advisory Database, and secret scanning by default without requiring a GitHub Advanced Security license; verify repository settings rather than assuming the default remained enabled. CodeQL 2.26.0 also adds js/system-prompt-injection for untrusted JavaScript/TypeScript data flowing into system prompts. Pair pattern-based SAST with contextual review for cross-function data flow and broken access control.Built-in agent validation covers only the scanner classes and languages the platform documents; it does not satisfy the full SAST/IAST/DAST/IaC/SCA set by itself. The new CodeQL query finds static flows into system prompts, not adversarial content that arrives at runtime, and automated agent remediation still needs independent review. Require scanners to surface a reproducible witness, vulnerable-version evidence, or violated invariant before treating contextual findings as blocking.
AC.4.3Verify that pull requests containing AI-generated code are blocked from merging when an automated scan surfaces a critical security finding, defined as CVSS >= 9.0 or the equivalent threshold in the organization's vulnerability severity policy. Bypassing the block requires a written exception approved by an authorized human.2Critical scanner findings ignored as advisory noise; agent-generated pull requests merged before humans triage exploitable flaws; policy bypass where code scanning reports exist but are not enforced.Review branch protection, repository rulesets, or CI quality gates to confirm findings at the defined threshold (CVSS >= 9.0 or organizational equivalent) block merge. In GitHub, verify code scanning merge protection rulesets and required status checks for CodeQL, Semgrep, SCA, secret scanning, and DAST jobs. Test with a deliberately vulnerable PR and confirm the merge is blocked. Verify the exception path: a bypass requires a written, attributable approval from an authorized human, retained as a record.The 2026 source pins the threshold (CVSS >= 9.0 or documented policy equivalent) and formalizes the exception process — auditors should sample exception records, not just confirm the gate exists. GitHub's code scanning merge protection has coverage caveats for merge queues and Dependabot defaults, so test the exact repository workflow.
AC.4.4Verify that security-critical files require an elevated review threshold when AI generated or modified them: two-person review, security-team sign-off, or stricter. Security-critical files here include authentication, authorization, and cryptography code; IAM policy; CI/CD workflow definitions; deployment manifests; and sandbox or network policy artifacts.2Broken access control is the dominant flaw class in AI-generated code — DryRun Security's March 2026 agent testing found it universal across Claude Code, Codex, and Gemini PRs, and Apiiro measured privilege-escalation paths up 322% in AI-assisted commits. A single AI-modified CI/CD workflow or IAM policy can compromise the whole pipeline (tj-actions, Ultralytics).Verify CODEOWNERS or platform path-based rules route the named file classes (auth/authz/crypto code, IAM policy, CI/CD workflow definitions, deployment manifests, sandbox/network policy) to elevated review — two-person or security-team sign-off — whenever AI generated or modified them. Test by raising an AI-attributed PR touching a workflow file and confirming the stricter gate fires. Overlaps with AC.12.5 for workflow files specifically.New requirement in the 2026 source. Path-based routing is easy; knowing the change was AI-generated is not — enforcement depends on AC.7.1/AC.10 attribution labels, which developers can strip. Treat "AI-touched" as the default assumption for these paths in organizations with high assistant adoption.
AC.4.5Verify that differential fuzz testing or property-based tests cover the security-critical behaviors of AI-generated code: input validation, authorization logic, and deserialization safety.3Logic errors and edge-case vulnerabilities that pass static analysis but fail under adversarial inputs; AI-generated input validation that misses boundary conditions, Unicode edge cases, or authorization invariants; insecure deserialization (CWE-502 was the third most frequent CWE in 2026 AI-generated code samples).Review test suites for property-based tests (Hypothesis for Python, fast-check for JS/TS, QuickCheck for Haskell) or fuzz testing (AFL, libFuzzer, Jazzer). Confirm security-critical code paths — auth, input validation, parser boundaries, deserialization, crypto wrappers — have negative tests and fuzz/property coverage. The 2026 SMT-backed "Broken by Default" study showed scanners alone miss exploitability witnesses, reinforcing this layer.AI tools can generate property-based tests, but those tests still need review — a test asserting a trivial property provides false assurance. Differential fuzzing against a trusted reference implementation is especially valuable when a reference exists. Deserialization safety is newly explicit in the 2026 text.

AC.5 Explainability & Traceability of Code Suggestions

Provide auditors and developers with insight into why a suggestion was made and how it evolved.

#RequirementLevelThreat MitigatedVerification ApproachGaps / Notes
AC.5.1Verify that prompt-and-response pairs are logged with stable correlation identifiers, so that an investigator can later replay the whole chain: prompt → response → commit → build → deployment.1Inability to trace the origin of vulnerable code back to a specific AI interaction; lack of forensic evidence during incident response; no audit trail for compliance. For AI systems deployed in EU high-risk contexts (credit scoring, hiring, benefits, insurance pricing, triage), EU AI Act Article 12 logging obligations apply, with penalties up to €15 million or 3% of worldwide annual turnover for non-compliance.Check for logging infrastructure that captures AI interactions. Verify logs include timestamps, prompt text (or hash), response text (or hash), and associated commit SHA. Confirm logs are retained per organizational retention policy — Articles 19 and 26 mandate a minimum six-month retention for high-risk systems, with longer periods possible depending on sector rules. Verify logs are generated automatically (manual records do not satisfy Article 12).Claude Code logs interactions locally in JSONL format. Copilot Enterprise provides an audit log API. For other tools, organizations may need to build custom logging via proxy or IDE extension hooks. Logging full prompt/response pairs may conflict with AC.3.3 data minimization goals; hashing or summarizing may be a compromise. Tamper-evidence gap: Article 12 doesn't explicitly require "tamper-proof" logs, but modified records without evidence of tampering lose evidentiary value. Practical fix: cryptographically sign each log entry with a signing key held outside the agent's trust boundary (e.g., a separate signer service), creating a verifiable chain that breaks visibly if entries are altered.
AC.5.2Verify that developers can pull up the citations (training snippets, retrieved documents, MCP tool outputs) that support a suggestion, and that the citation chain travels with the artifact.3Acceptance of AI-generated code that closely replicates copyrighted or GPL-licensed training data without attribution; use of code patterns from vulnerable or deprecated libraries; inability during incident response to determine which retrieved document or MCP tool output steered a bad suggestion (relevant when the source itself was poisoned).Verify the AI tool provides citation or reference information (e.g., Copilot's code referencing filter, Sourcegraph Cody's context sources). The 2026 text adds two checks: MCP tool outputs are included in the citation surface, and the citation chain is persisted with the artifact (commit trailer, attestation, or linked log record), not just shown transiently in the IDE.The 2026 source raised this from Level 2 to Level 3 and widened it to retrieved documents and MCP outputs — realistic, since true training-data attribution remains an unsolved research problem and current tools provide repository-level references at best. Persisting citation chains with artifacts has essentially no off-the-shelf tooling; expect bespoke commit-metadata or attestation schemes.
AC.5.3Verify that explainability reports, AI-event logs, and citation records are kept in tamper-evident storage (append-only, WORM, or an immutable log store) and are referenced during security reviews.3Modified or deleted AI-event records destroying evidentiary value during audits, litigation, or incident response; a compromised agent (or its operator) erasing the logs that would reveal the compromise. EU AI Act Article 12 logging obligations apply to high-risk deployments, with penalties up to €15 million or 3% of worldwide turnover.Verify the storage layer, not just the logs: append-only stores, WORM object-lock buckets (e.g., S3 Object Lock), or immutable log services. Confirm AI-event logs and citation records land there automatically and that security review records reference them. Cryptographically signed log entries with the signing key outside the agent's trust boundary provide a verifiable chain that breaks visibly if entries are altered. Map records onto the European Commission's draft Article 50 guidelines (May 8, 2026) and ISO/IEC 42001 Clause 7.5.The 2026 source converts the old "store explainability reports with design artifacts" control into a tamper-evidence requirement — a meaningful upgrade given the May 2026 finding that Article 12 does not explicitly require tamper-proof logs yet unverifiable records lose evidentiary value. ISO 42001 certification is still emerging; report formats remain non-standardized (tool, model version, prompt summary, review outcome, risk assessment is a workable minimum).

AC.6 Continuous Feedback, Adversarial Testing & Model Fine-Tuning

Improve model security over time, watch for negative drift, and keep red-teaming the AI tooling itself. The 2026 source renames this family to add adversarial testing as a standing obligation, not a one-time onboarding step.

#RequirementLevelThreat MitigatedVerification ApproachGaps / Notes
AC.6.1Verify that developers and reviewers can flag insecure or non-compliant suggestions, and that each flag is tracked to closure with links back to the originating prompt and response and forward to any downstream artifacts.1Repeated generation of known-insecure patterns with no mechanism for correction; developer frustration leading to workarounds that bypass security controls.Confirm a feedback mechanism exists (e.g., thumbs-down in Copilot, feedback forms, issue tracker labels). Verify flags are aggregated and reviewed periodically. Check that high-severity flags trigger investigation.GitHub Copilot and Cursor both support inline feedback. For CLI tools like Claude Code, feedback may need to be captured via separate channels (Slack, issue trackers). The 2026 text adds bidirectional traceability — each flag links back to the prompt/response pair (requires AC.5.1 correlation IDs) and forward to downstream artifacts — which no commercial feedback mechanism provides natively; expect a bespoke tracker integration.
AC.6.2Verify that aggregated feedback feeds into periodic system-prompt updates or retrieval-augmented generation against vetted secure-coding corpora (OWASP Cheat Sheets, internal coding standards). Where the organization controls model training infrastructure, fine-tuning on the same feedback corpus is also required.2AI models persistently suggesting insecure patterns because feedback is not incorporated; missed opportunity to improve model output using organization-specific secure coding standards.Review evidence that feedback data is used in model improvement cycles (fine-tuning logs, RAG corpus updates). For RAG-based systems, verify the retrieval corpus includes vetted sources (OWASP, CWE, organization-specific secure coding guides). Confirm update cadence (at least quarterly). The OpenSSF Security-Focused Guide for AI Code Assistant Instructions provides a baseline for secure instruction files.Most organizations cannot fine-tune commercial models (Copilot, Claude) directly. RAG is the practical alternative: maintain a curated knowledge base of secure coding patterns that the AI tool references. Cursor supports .cursorrules, Claude Code supports CLAUDE.md, Copilot supports .github/copilot-instructions.md. The OpenSSF guide (2025) recommends Recursive Criticism and Improvement (RCI) — instructing the AI to review and improve its own output iteratively — as a practical security enhancement. These instruction files serve as lightweight RAG mechanisms but must themselves be protected against prompt injection (see IDEsaster CVEs).
AC.6.3Verify that scheduled red-team exercises target the AI tooling itself. The exercises include direct and indirect prompt-injection probes delivered through realistic PR, issue, and comment surfaces, jailbreak corpora, and supply-chain payload generation. Findings are remediated under tracked severity SLAs.2The tooling drifting into exploitability between point-in-time evaluations — every major coding agent (Claude Code, Gemini CLI, Copilot Agent) was shown injectable through PR/issue/comment surfaces in the October 2025–April 2026 Comment-and-Control window, and Datadog's hackerbot-claw post-mortem showed attackers actively probing LLM review workflows with injection payloads in February 2026.Review the red-team schedule and reports. Confirm the exercise scope covers the AI tooling itself (not just the apps it builds): indirect injection via simulated PRs, issues, and comments; jailbreak corpora; and supply-chain payload generation (can the assistant be steered into emitting a malicious workflow file or hallucinated dependency?). Tools: Microsoft PyRIT, garak, promptfoo red-team mode. Verify findings carry severity ratings and tracked remediation SLAs.New requirement in the 2026 source, complementing the one-time AC.2.3 onboarding test with a recurring program. The scope boundary matters for cost: the AI tooling is in scope, the underlying services are handled by existing programs. Few organizations red-team their coding assistants today; the published Comment-and-Control and hackerbot-claw payload patterns are the natural seed corpus.
AC.6.4Verify that a closed-loop evaluation harness runs regression tests after every fine-tune, system-prompt change, or model upgrade. Security metrics must meet or exceed the prior baseline before deployment.3Model fine-tuning, system-prompt edits, or silent model upgrades introducing regressions where previously secure patterns become insecure; degraded security performance going undetected after updates.Review the evaluation harness design. Confirm it includes a benchmark suite of security-relevant code generation tasks (e.g., generate parameterized SQL, generate CSRF-protected forms) and injection-resistance probes. The 2026 text adds system-prompt changes and model upgrades as mandatory triggers, not just fine-tunes. Verify pass/fail criteria and evidence that deployment is gated on results.Benchmarks like CyberSecEval (Meta), SecurityEval, and SVEN provide standardized security evaluation for code-generating models. The expanded trigger set matters for commercial-tool users: organizations cannot fine-tune Copilot or Claude, but they do control system prompts and instruction files, and vendors swap underlying models — both now require a regression run. Veracode's Spring 2026 data (security pass rates flat at ~55% across model generations) shows upgrades cannot be assumed to be security-neutral.

AC.7 AI-Generated Infrastructure & Pipeline Artifacts

Ensure that AI-generated infrastructure-as-code (IaC), CI/CD workflows, deployment configurations, and security policy artifacts are subject to appropriate validation and governance controls.

#RequirementLevelThreat MitigatedVerification ApproachGaps / Notes
AC.7.1Verify that AI-generated or AI-modified artifacts are clearly labeled and tracked as such. Artifact classes in scope include infrastructure-as-code (Terraform, CloudFormation, Pulumi, Bicep), CI/CD workflow files (GitHub Actions, GitLab CI, Jenkinsfile, Argo Workflows, Tekton), container and orchestration manifests (Dockerfile, Kubernetes, Helm), and security policy artifacts (IAM, OPA/Rego, NetworkPolicy, admission controllers).1AI-generated infrastructure deployed without awareness of its origin; inability to prioritize security review for machine-generated infrastructure changes. The 2026 scope expansion to security policy artifacts matters most: an AI-modified NetworkPolicy or admission controller silently weakens the very controls other requirements depend on.Check version control for labeling conventions, PR labels, file headers, or internal artifact manifests that identify AI-generated or AI-modified artifacts across all four named classes — IaC, CI/CD workflow files, container/orchestration manifests, and security policy artifacts. Verify an inventory or registry tracks them.Convention-based tracking works best when backed by internal manifests, signed metadata, or deployment records rather than informal commit text. "AI-modified" (not just AI-generated) is now in scope, which roughly doubles the tracking surface in assistant-heavy teams. Automated enforcement via pre-commit hooks or CI checks can validate labeling.
AC.7.2Verify that AI-generated infrastructure and pipeline configurations require human review and approval before they run in any environment beyond a hermetic sandbox.2AI-generated IaC with overly permissive IAM policies, open security groups, unencrypted storage, or disabled logging reaching shared environments without scrutiny — including "harmless" dev environments that share networks, credentials, or state with production.Verify branch protection or pipeline gates require human approval for AI-generated infrastructure changes before execution anywhere beyond a hermetic sandbox (no shared network, credentials, or state). Confirm review checklists include IaC-specific security checks (least privilege, encryption, network segmentation). Check that Terraform plan / CloudFormation changeset review is mandatory.The 2026 text replaces "prior to execution" with the sharper "beyond a hermetic sandbox" boundary — agents may iterate freely in genuinely isolated sandboxes, but anything with shared reach needs human approval first. Truly hermetic sandboxes are rarer than teams assume; cloud dev accounts usually share IAM trust or networking with the org.
AC.7.3Verify that AI-generated infrastructure and workflow changes pass policy-as-code enforcement (OPA, Conftest, Checkov, tfsec, KICS, kube-linter) at the same level as, or stricter than, human-authored changes. Policy violations block promotion.2IaC treated as a second-class artifact with weaker security gates than application code; AI-generated GitHub Actions workflows with excessive permissions or unsafe third-party action references; policy reports generated but not enforced.Verify that the named policy-as-code tools (or equivalents) run in CI with blocking enforcement — a violation stops promotion, not just files a report. Confirm coverage parity or stricter posture versus human-authored changes. For workflow files specifically, add zizmor or poutine, which detect pull_request_target misuse, persisted credentials, template injection, and unpinned actions that generic IaC scanners miss.The 2026 source moved this from Level 3 to Level 2 and made blocking explicit. CI/CD workflow files remain the highest-value target; BoostSecurity's poutine MCP server (October 2025) now lets coding agents validate agent-generated CI/CD YAML before commit — a guardrail worth requiring for agent-authored pipelines.
AC.7.4Verify that changes to high-impact pipeline trigger configurations require both dual control and a security-team review, no matter who or what produced the change. The configurations in scope include GitHub Actions pull_request_target and workflow_run, self-hosted runner labels, workflow permissions: blocks, OIDC trust policies, and secret-environment mappings.2A single trigger-configuration change converting an unprivileged workflow into a privileged one: every major fork-PR exploitation campaign — Ultralytics (December 2024), tj-actions (March 2025), prt-scan (March 2026), hackerbot-claw (February 2026) — ran through pull_request_target/workflow_run-class trigger semantics or the secrets they expose. OIDC trust-policy edits can silently grant external workloads cloud access.Verify path-based platform rules (CODEOWNERS on .github/workflows/, repository rulesets) route the named configuration classes to dual control plus security-team review, with no bypass for bots or agents. Audit recent changes to pull_request_target/workflow_run triggers, runner labels, permissions: blocks, OIDC trust policies, and secret-environment mappings for evidence both gates fired. Scan continuously with zizmor (dangerous-triggers audit) or OpenSSF Scorecard's Dangerous-Workflow check.New requirement in the 2026 source, directly encoding the post-incident lessons of 2025-2026. GitHub's December 8, 2025 secure-by-default change (anchoring pull_request_target to default-branch workflow definitions) closed the classic variant, but TOCTOU, non-default-branch, and cache/artifact-poisoning patterns from GitHub Security Lab's "pwn requests" Part 4 (January 2025) remain live.
AC.7.5Verify that drift detection compares deployed infrastructure and live workflow configurations against signed, AI-attributed baselines, and alerts on any unauthorized modification.3Post-approval drift: an agent or attacker modifying live infrastructure or workflow configuration after the reviewed baseline was deployed — the gap that review-time controls (AC.7.2-AC.7.4) cannot see. The prt-scan campaign specifically posed as fake CI updates, counting on nobody comparing live workflows to a trusted baseline.Verify drift detection runs continuously: Terraform plan drift checks, AWS Config / Azure Policy, GitOps reconciliation (Argo CD, Flux) for manifests, and periodic diffing of live workflow definitions against the signed baseline. Confirm baselines are signed and carry AI-attribution metadata (which artifacts were AI-generated, per AC.7.1), and that unauthorized deltas page a human.New requirement in the 2026 source. Standard drift tooling covers cloud resources well; workflow-definition drift detection is far less mature — few tools diff live CI configuration against signed baselines, so expect custom automation. The "signed, AI-attributed baseline" combines AC.9 signing with AC.7.1 labeling; organizations without those foundations cannot satisfy this control.

AC.8 Autonomous Agent Change Control Constraints

Ensure that autonomous AI agents involved in code or configuration generation are subject to appropriate separation of duties and cannot independently approve or promote their own changes.

#RequirementLevelThreat MitigatedVerification ApproachGaps / Notes
AC.8.1Verify that autonomous agents cannot approve, merge, sign, or deploy artifacts that they themselves generated, and that this constraint is enforced by the source-control system, the CI system, and the artifact registry. Policy alone does not satisfy this control.1AI agent autonomously generating and deploying malicious or vulnerable code without human oversight; compromised agent credentials used to push unauthorized changes to production. The Meta AI agent Sev-1 incident (March 2026) demonstrated real-world consequences: an autonomous agent posted unauthorized guidance that an employee followed, triggering a privilege escalation chain exposing sensitive data to unauthorized engineers.Review repository permissions, CI/CD configurations, and artifact-registry ACLs to confirm AI agent accounts lack merge/approve/deploy/sign permissions in all three layers — the 2026 text explicitly rules out policy-only compliance. Test by attempting agent self-approval in a staging environment. Verify branch protection rules exclude agent identities from approvers.Critical for Claude Code, Copilot coding agent, Devin, SWE-agent, and similar autonomous agents. Datadog's hackerbot-claw post-mortem (March 2026) validates the technical-enforcement framing: rulesets requiring PRs on default branches plus Actions tokens denied PR create/approve meant the attacking agent could only push test branches — no secrets exposed, no rotation needed. The Meta Sev-1 incident (March 2026) shows the principle extends beyond code to any autonomous action with downstream effects.
AC.8.2Verify that AI systems run with scoped, non-human identities (service accounts, workload identities, OIDC-issued ephemeral tokens), and that those identities cannot be used to promote their own generated artifacts across environments.2Privilege escalation where an AI agent with write access to a development environment also has access to staging or production; lateral movement from compromised agent credentials.Audit AI agent service accounts for least-privilege permissions. Verify separate credentials per environment (dev/staging/prod). Confirm no shared secrets or cross-environment access. Review IAM policies for AI agent roles.AI agents should use dedicated non-human identities (the 2026 text names service accounts, workload identities, and OIDC-issued ephemeral tokens explicitly), never developer personal tokens — the tj-actions compromise (March 2025) started from a bot PAT. GitHub Apps with scoped repository permissions beat PATs; OIDC-issued tokens that live minutes beat both. Environment-specific credentials prevent a compromised dev agent from reaching production.
AC.8.3Verify that autonomous agents cannot bypass branch protection, required reviews, required status checks, signed-commit requirements, or merge queues. Any attempt by an agent to change these settings raises a security alert.2An agent — prompt-injected or simply misaligned — editing the protections that constrain it: disabling branch protection, dismissing required reviews, or rewriting rulesets. CVE-2025-53773 demonstrated the adjacent pattern (Copilot modifying project configuration files to achieve code execution); at platform level, an agent identity with admin scope can deactivate every other control in this appendix.Audit agent identities for repository-admin or ruleset-edit permissions — they should have none. Verify platform audit-log streaming alerts on protection-setting changes (GitHub protected_branch.* / ruleset events) attributed to agent identities. Test in staging: have an agent attempt to modify branch protection and confirm the attempt fails and pages a human. On GitHub, configure the ruleset's review-dismissal restriction so its user, team, and app allow-list excludes every agent identity; also confirm the ruleset's separate bypass-actor list contains no agent role, team, or app. Then verify an agent cannot dismiss an approval through either the UI or API. OpenSSF Allstar can continuously enforce branch-protection posture and revert drift.New requirement in the 2026 source. GitHub made actor-level review-dismissal restrictions generally available in July 2026, closing one concrete bypass path when configured correctly. The control still has two halves — prevention (no permission to change settings) and detection (alert on attempts) — and the second remains commonly missed: most organizations do not alert on ruleset changes at all, let alone segment alerts by agent identity.
AC.8.4Verify that separation of duties holds across the stages of an AI-generated change. Each stage (generation, review, approval, deployment) is performed by a distinct principal, whether human or system.3Complete bypass of change management when an AI agent controls the full pipeline from code generation through deployment; audit failures due to lack of independent verification at each stage.Map the end-to-end change pipeline and verify distinct principals at each stage (generation, review, approval, deployment). Confirm no single identity participates in more than one stage. Review audit logs for evidence of multi-party involvement. SLSA v1.2 Source Track L4 (two-party review by trusted persons, with documented exceptions for trusted robots) is the formal target state.Full four-way separation is aspirational for many organizations. A practical minimum is two-way (AI generates, human approves); three-way (AI generates, human reviews, different human/system deploys) suits mature organizations. The 2026 phrasing "whether human or system" legitimizes system principals at some stages — e.g., a deployment controller — as long as principals stay distinct. Enforce via CODEOWNERS, required reviewers, and deployment approval gates.

AC.9 AI Artifact Origin Validation for Deployment

Ensure that deployment and promotion pipelines validate the origin and generation history of AI-generated artifacts before they are promoted.

#RequirementLevelThreat MitigatedVerification ApproachGaps / Notes
AC.9.1Verify that AI-generated artifacts carry signed origin and generation metadata (in-toto or SLSA provenance attestations, AI BOM entries) identifying the AI system that produced them, the generation context, the humans involved, and the associated audit records.2Deployed artifacts with unknown origin making incident response and root cause analysis difficult; inability to determine whether a vulnerability was introduced by human or AI, hindering targeted remediation. As of March 2026, Georgia Tech researchers have tracked 74 CVEs directly attributed to AI-generated code since May 2025, with the actual count estimated at 5-10x higher due to stripped AI signals.Inspect AI-generated artifacts for origin metadata (e.g., internal manifests, file headers, SLSA provenance attestations). Verify metadata includes: generating tool class/version, model identifier, timestamp, and link to prompt/response logs. The AIBOM (AI Bill of Materials) framework extends CycloneDX to capture model identity, training data lineage, and execution context — the open-source aibom-toolkit supports automated generation.SLSA provides a framework for provenance attestations. For AI-generated code, origin metadata should minimally include the approved tool class, model identifier, timestamp, and a reference to the interaction log in a controlled manifest or attestation. The EU AI Act Article 50 transparency obligations (enforceable August 2026) require machine-readable disclosure for AI-generated content; the Draft Code of Practice (second draft, March 2026) permits "Provenance Certificates" — digitally signed manifests guaranteeing content origin — as an alternative to watermarking for text and code outputs.
AC.9.2Verify that deployment pipelines check the presence, signature, and integrity of origin and generation metadata on AI-generated artifacts before promotion, using a trusted verifier (Sigstore/cosign, in-toto verification).3Artifacts with missing or tampered origin metadata reaching production; circumvention of origin tracking requirements by stripping metadata before deployment. Georgia Tech research indicates developers increasingly "vibe code entire projects, shipping code they've barely read," making pipeline-enforced origin validation critical.Review CI/CD pipeline configuration for origin validation steps. Test by submitting an artifact without origin metadata and confirming it is rejected. Verify integrity checks (e.g., signed provenance attestations via Sigstore/cosign, hash verification via in-toto). GitHub's built-in attestation support achieves SLSA Level 2 for most artifact types with minimal setup.Sigstore provides keyless artifact signing using short-lived certificates tied to OIDC identities. In-toto's Attestation Framework (ITE-6) defines the common envelope used by SLSA, Sigstore, and other tools. For most organizations, a CI check validating commit metadata is a practical starting point before implementing full cryptographic attestation — but note the 2026 source moved this control to Level 3 and now requires a trusted verifier, so unsigned metadata checks no longer satisfy it. SLSA v1.2 (approved November 2025) added the Source Track, whose source VSAs give verifiers first-class evidence about authorship and review of AI-authored commits.
AC.9.3Verify that artifacts are rejected at deployment and quarantined for review when they are missing required origin and generation information, signed by untrusted keys, or produced by an unapproved AI system or environment.3Artifacts generated by unauthorized or compromised AI tools entering the deployment pipeline; shadow AI usage where developers use unapproved tools and strip origin metadata to avoid detection. The OpenClaw/ClawHub supply chain attack remains the canonical example: 1,184 malicious skills confirmed by Antiy CERT (~1 in 5 packages at peak), with Snyk's February 2026 ToxicSkills audit finding 534 skills (13.4%) containing critical issues and 1,467 (36.82%) containing any flaw across 3,984 skills reviewed. Koi Security independently audited 2,857 skills and found 341 malicious entries (335 traced to a single "ClawHavoc" campaign).Verify deployment pipeline includes a rejection mechanism for missing origin metadata. Test with artifacts from an untrusted source. Confirm rejected artifacts generate alerts. Review the approved tool allowlist and confirm it is enforced. AIBOM validation can automate checks for required origin fields. For agent-skill ecosystems, run mcp-scan (open-source) or equivalents like Snyk Evo / Agent Guard to detect malicious skills before install.Maintaining an allowlist of trusted generation environments requires ongoing governance. The EU AI Act Draft Code of Practice (second draft, March 2026) requires providers to "preserve provenance information throughout the content lifecycle and prevent deliberate removal or alteration of markings." The final Code of Practice is expected June 2026, mandating C2PA machine-readable metadata for content provenance and naming W3C PROV as the cross-modal standard for code and text artifacts. Consider a graduated approach: warn on missing origin data at Level 1, block at Level 2, require cryptographic attestation at Level 3.

AC.10 Generation Audit Trail Completeness and Validation

Ensure that AI-generated artifacts include complete and consistent origin and generation records, and that these records are validated prior to integration or deployment. In practice, policy-based enforcement depends on the availability and quality of origin and generation records. Incomplete or inconsistent records can lead to missed detections or enforcement gaps.

#RequirementLevelThreat MitigatedVerification ApproachGaps / Notes
AC.10.1Verify that AI-generated artifacts carry the required origin and generation fields: model identity and version, tool or agent identity, generation context, prompt hash, human involvement, session identifiers, and correlation IDs.1Artifacts deployed without traceable generation history; inability to correlate a vulnerability with the specific AI system, model version, or session that produced it. As of March 2026, 74 confirmed CVEs have been attributed to AI-generated code (Georgia Tech), but the actual number is estimated at 5-10x higher because AI origin signals are routinely stripped.Review AI-generated artifacts for required metadata fields. Check commit messages, file headers, or dedicated metadata files for: model identity (e.g., "claude-sonnet-4"), generation context (prompt hash or session ID), human involvement flag (fully autonomous vs. human-in-the-loop), and timestamp. Verify against an organizational schema defining required fields.The AIBOM framework (Frontiers in Computer Science, 2026) proposes extending CycloneDX to capture model artifacts, dependencies, infrastructure, configuration, execution context, and disclosure controls. The aibom-toolkit provides open-source tooling for automated AIBOM generation. Minimum viable metadata: tool name, model identifier, timestamp, session ID, and human-involvement flag.
AC.10.2Verify that origin and generation metadata is checked for completeness and consistency: no missing or ambiguous fields, values normalized to a single representation, and a signature chain that validates back to a trusted root.2Incomplete or inconsistent origin records creating enforcement gaps; metadata that passes presence checks but contains ambiguous or conflicting values (e.g., mismatched timestamps, unknown model identifiers) undermining audit reliability.Implement automated validation rules in CI/CD pipelines that check metadata completeness (all required fields present), consistency (timestamps within expected ranges, model identifiers on approved list), and normalization (standardized date formats, canonical tool names). Test by submitting artifacts with deliberately incomplete or malformed metadata.The EU AI Act Draft Code of Practice (second draft, March 2026) requires "normalized representations" for origin tracking. SLSA's in-toto Attestation Framework (ITE-6) provides a standardized envelope format. Validation schemas should be versioned and maintained alongside the allowlist of approved AI tools. Consider JSON Schema or CUE for machine-readable validation rules.
AC.10.3Verify that artifacts with incomplete, inconsistent, or unverifiable origin and generation metadata are rejected before merge or deployment, and that the rejection event is logged so trends can be tracked. Rejection happens on the verifier side, against the attestation or proof model defined in SLSA and the verification criteria in ISO/IEC 42001.3Artifacts with unverifiable origin reaching production, defeating the purpose of audit trail requirements; circumvention via minimal-effort metadata that technically passes presence checks but lacks verifiable integrity. The Meta AI agent Sev-1 incident (March 2026), where an autonomous agent took unauthorized action leading to privilege escalation, illustrates the consequences when generation audit trails are absent for autonomous AI actions.Verify that CI/CD pipelines enforce hard rejection for artifacts failing metadata validation. Test by submitting artifacts with incomplete, inconsistent, or unsigned metadata and confirming they are blocked. Review rejection logs for alert generation. Confirm cryptographic verification of metadata integrity where Sigstore/cosign attestations are used.Full cryptographic attestation (SLSA Level 3+) is the gold standard but requires significant infrastructure investment. A practical progression: Level 1 — require presence of origin fields; Level 2 — validate completeness and consistency; Level 3 — require cryptographic signatures and reject unverifiable attestations. The OpenClaw attack (1,184 malicious packages) demonstrates the risk when origin validation is absent from AI ecosystems.

AC.11 AI Code-Review & Assistant Bot Hardening

New family in the 2026 source. AI code-review bots, PR-comment bots, MCP-driven assistants, and IDE copilots are all reachable through untrusted repository content — PR diffs, descriptions, comments, issues, and fork-supplied workflow files. This family covers the case where an attacker uses one of those surfaces to push a defender's own AI agent into approving, ignoring, or actively assisting a supply-chain attack. AC.11.1–AC.11.5 apply AISVS C2.1 (Prompt Input Validation), C9.3 (Tool Sandboxing), and C9.6 (Action Authorization) to the bot case; assessors count findings here or under the chapter, not both.

#RequirementLevelThreat MitigatedVerification ApproachGaps / Notes
AC.11.1Verify that AI review and assistant bots treat every piece of PR-supplied content (diff, title, description, comments, file contents, commit messages, linked external URLs) as untrusted input, and apply the AISVS C2.1 prompt-injection defenses: instruction-hierarchy enforcement, content sanitization, and indirect-injection detection.1Comment-and-Control hijacked Claude Code Security Review, Gemini CLI Action, and GitHub Copilot Agent through PR and issue content to exfiltrate credentials. The July 2026 agent-data-injection work demonstrated another route against Claude Code, Codex, and Gemini CLI: PR text forged tool-call and tool-response delimiters, causing agents to believe they had reviewed malicious code and merge it. Ordinary prompt-injection defenses reduced instruction-injection success to 0.0-0.7% in that evaluation while data injection still reached 50%.Enumerate every PR-supplied content type the bot ingests and verify each passes through sanitization and injection screening. Replay Comment-and-Control and CamoLeak patterns, then add agent-data-injection payloads that mimic author metadata and tool blocks. Confirm the bot derives identity from authenticated platform fields, obtains diffs through an independent trusted call, records the actual tool-call transcript outside prompt text, and refuses to merge when those sources disagree.Classifier-based detection is bypassable and may not flag structural delimiter injection at all. A model-visible label such as author: maintainer is not proof of origin, and a model-visible tool-result block is not proof that a tool ran. Bind both to authenticated, typed data outside the prompt and layer this control with AC.11.4 sandboxing and AC.11.5 policy-gated actions.
AC.11.2Verify that AI review and assistant bot system prompts and policy configurations are integrity-checked at load time (signed, hash-pinned), and that nothing in the repository, in branch contents, in PR-sourced environment variables, or in any other user-controllable input can modify them.1Configuration-file weaponization: CVE-2025-59536 (Claude Code RCE via .mcp.json/settings files), the IDEsaster class (December 2025), and the CodeRabbit incident — where a .rubocop.yml in a PR was loaded by a privileged tool, yielding RCE on production servers and exposure of a GitHub App private key with access to 1M+ repositories (disclosed August 2025).Verify the bot loads system prompts and policy configuration from a signed or hash-pinned source outside the analyzed repository. Test with a hostile workspace: place modified bot configuration, instruction files, and tool configs in a PR branch and confirm the bot ignores them. Check that PR-sourced environment variables cannot redirect model endpoints (the CVE-2026-21852 ANTHROPIC_BASE_URL pattern). For GitHub Copilot CLI and VS Code, verify managed-setting delivery uses native MDM on Windows/macOS or the documented platform file path; for Copilot CLI on POSIX, confirm managed-settings.json is root-owned, not world-writable, and not a symlink. Use the CLI configuration reference to negative-test precedence per key: permissions.disableBypassPermissionsMode: "disable" is explicitly non-overridable, while model is only a default. Exercise strictKnownMarketplaces, enabledPlugins, and extraKnownMarketplaces against user and repository overrides, and do not accept managed delivery alone as control evidence where an override succeeds.The CodeRabbit incident is the canonical failure: the bot's own linter config loading path, not its prompt, was the injection vector — integrity checking must cover every config file any invoked tool reads, which is a much larger surface than the bot's system prompt. GitHub's delivery feature is generally available for Copilot CLI and VS Code, but Copilot CLI treats most managed keys as an overridable baseline; only the bypass-permission disable is documented as always winning, and enterprise plugin standards remain in public preview. Managed settings alone therefore do not satisfy this control for model or plugin policy unless negative tests prove the chosen keys cannot be overridden.
AC.11.3Verify that AI review and assistant bots emit only structured, schema-validated output (JSON with an allow-list of fields and actions). Any free-form output is treated as untrusted and never executed as a command, a query, a shell snippet, or a workflow step.1Injected instructions surviving into bot output and being executed downstream — the "When prompts become shells" pattern (Microsoft Semantic Kernel CVE-2026-25592/CVE-2026-26030, May 2026) where prompt-controlled strings reached eval() and filesystem primitives; OWASP LLM05 Improper Output Handling and Agentic ASI05 Unexpected Code Execution.Review the bot's output contract: JSON Schema with field and action allowlists, validated before any consumer acts on it. Grep CI definitions for places bot output is interpolated into shell, SQL, or workflow YAML and confirm none exist. Test by inducing the bot (via injected PR content) to emit a shell command in a free-text field and confirming downstream systems treat it as inert data. Guardrails AI and plain JSON Schema validators both serve as enforcement layers.Schema validation constrains structure, not semantics — a validated "comment" field can still carry a social-engineering payload aimed at the human reader (OWASP ASI09 Human-Agent Trust Exploitation). Pair with AC.11.5 so even schema-valid actions go through policy adjudication.
AC.11.4Verify that AI review and assistant bots run in network-isolated, least-privilege sandboxes: a dedicated namespace, default-deny egress with an allow-list to approved APIs only, no mounted repository secrets, and ephemeral credentials only.2Exfiltration as the impact stage of every bot-injection attack: Comment-and-Control payloads exfiltrated API keys precisely because agent runtimes had broad egress; the Claude Code SOCKS5 sandbox bypasses (April-May 2026) showed raw-TCP escape routes around HTTPS-only allowlists. AutoJack (June 2026) adds the loopback variant: a browsing agent can be confused into crossing from untrusted web content into a privileged localhost MCP control plane.Verify the bot's runtime: dedicated namespace/VM, default-deny egress with an explicit API allowlist, no repository secrets in the environment, and short-lived OIDC credentials. Test egress enforcement with raw TCP, SOCKS5, and loopback/localhost access to control sockets, not just HTTPS. Confirm MCP bridges, debug ports, local code executors, and dev databases require authentication and are unreachable from the agent's browsing identity. Reference deployments: GitHub Copilot cloud agent's firewall (on by default; org-level allowlist controls since April 3, 2026), Agent HQ's sandboxed Actions environments (multi-agent GA February 2026), and Anthropic-managed VMs for Claude Code on the web. StepSecurity harden-runner provides eBPF egress monitoring/blocking for Actions-hosted bots.Vendor-managed sandboxes have shipped multi-month bypass windows (Claude Code SOCKS5: ~130 versions over 5.5 months, silently patched) — treat them as defense-in-depth and validate egress independently. AutoJack was fixed before PyPI release, but its broader pattern means localhost, developer profiles, and MCP control planes must be modeled as reachable attack surface whenever the agent can browse or fetch untrusted content.
AC.11.5Verify that any privileged action a bot can take (approving a PR, merging, labeling, dismissing reviews, posting comments outside its sandbox, invoking external tools) goes through a separate, audited authorization path. That path is adjudicated by a policy engine, not by the LLM.2A prompt-injected bot using its own legitimate permissions as the attack payload — approving the malicious PR it was asked to review, dismissing human reviews, or invoking external tools for exfiltration. AutoJack shows the same issue at the framework layer: if tool invocation or MCP server launch parameters are reachable from untrusted content, the "privileged action" may be process creation rather than a GitHub API call.Map every privileged action the bot can perform and verify each routes through an external policy decision point (OPA or equivalent) that evaluates the action against rules the LLM cannot rewrite, with an audit record per decision. Include local actions in the map: spawning MCP servers, opening debug WebSockets, executing shell commands, accessing browsers, or connecting to localhost services. Test by prompt-injecting a staging bot into requesting a privileged action that policy should deny, and confirm denial plus alert.This is the control that holds when AC.11.1's detection fails, so its independence matters: the policy engine must not share the bot's process, credentials, or configuration surface. Off-the-shelf agent-to-OPA integration is still young; most deployments hand-roll the adjudication layer, and fewer still cover local control-plane actions such as MCP server launch allowlists.
AC.11.6Verify that AI review and assistant bots log all prompts (including externally sourced context), tool calls, and outputs to tamper-evident storage. Egress patterns (URLs, IPs, DNS, payload sizes) are continuously monitored for exfiltration indicators, with alerting tuned for webhook, paste-site, and bin-service destinations.2Silent compromise: injection attacks on bots leave no platform-native trace — the injected instruction arrives as ordinary PR text and the exfiltration leaves as an ordinary HTTP request. The prt-scan campaign (March 2026) deliberately exfiltrated only via the GitHub API and cloud metadata endpoints so no attacker-controlled C2 domain would appear in egress logs.Verify prompt/tool-call/output logging lands in tamper-evident storage (per AC.5.3) and includes the externally-sourced context segments, which is what forensics needs to find the injection. Review egress monitoring rules for webhook, paste-site, and bin-service destinations — and for "legitimate-looking" channels like api.github.com payload anomalies and metadata-endpoint access, the prt-scan lesson. Microsoft's prompt-abuse detection guidance (March 12, 2026) describes the detection patterns. For Copilot CLI and VS Code, test the enterprise-managed OpenTelemetry export against the enterprise settings reference: confirm telemetry.enabled, endpoint, protocol, telemetry.captureContent, and telemetry.lockCaptureContent resolve from policy ahead of environment variables and user settings, and verify the expected events reach the collector. Content capture is off by default; when enabled it can include full prompts, responses, system prompts, tool schemas, arguments, and results. Test downstream redaction and retention separately rather than assuming the exporter redacts content.Logging full prompts tensions with AC.3 data minimization; hashing context segments with raw retention only for flagged events is the emerging compromise. Managed telemetry.headers are applied only to the Copilot Chat extension exporter and kept out of environment variables and agent-spawned tool subprocesses; they are not delivered to the agent-host or CLI exporter in this release. Exported records still need tamper-evident downstream storage, access control, redaction, and retention. Egress baselining for bots is immature — payload-size anomaly detection on allowlisted domains is the practical frontier, since attackers have moved inside the allowlist.
AC.11.7Verify that AI review bots run in a zero-privilege, read-only shadow mode for untrusted fork PRs. In shadow mode, inline code-generation commentary is restricted and privileged workflow interaction is forbidden, until a repository maintainer has cleared an initial first-time-contributor verification gate.2Attackers using fork PRs as free injection delivery: hackerbot-claw (February 2026) — an autonomous agent self-described as Claude-powered — ran a fork-and-PR campaign against Microsoft, Datadog, Aqua, and CNCF repositories, including a prompt-injection attempt against Datadog's LLM review workflow, and achieved RCE in 5 of 7 targets. Fork PRs reach the bot before any human trust decision.Verify the bot's configuration distinguishes fork PRs from branch PRs and that fork PRs get read-only treatment: no write-scoped tokens, no secret access, restricted commentary, no privileged workflow interaction. Confirm the maintainer gate mirrors GitHub's first-time-contributor workflow approval (the platform default since 2021) and that bot-level enforcement does not substitute for platform-level enforcement (AC.12.3). Test with a fork PR from a fresh account.New control with direct incident validation: Datadog's layered defenses (deny-by-default Actions tokens plus model-level injection refusal) contained hackerbot-claw to pushing test branches. Shadow mode is not yet a named feature in most commercial review bots — implementers typically approximate it with conditional workflow logic, which is fragile.
AC.11.8Verify that AI review and assistant bots are subject to continuous adversarial testing: indirect-prompt-injection corpora are replayed against the bot through simulated PRs, issues, and comments. Detection effectiveness is tracked over time, and a regression blocks the model or prompt update that caused it.3Injection resistance degrading silently across model swaps and prompt updates — vendors change underlying models without notice, and the Comment-and-Control timeline (vulnerable from at least October 2025 to April 2026) shows how long regressions persist undetected.Review the testing harness: replay Comment-and-Control, CamoLeak, and hackerbot-claw patterns plus July 2026 agent-data-injection cases that forge author roles and tool-call history. Track instruction-injection and data-injection success separately; a model can improve on the former while remaining vulnerable to the latter. Run the corpus on every model, prompt, context serializer, or tool-adapter change and block regressions.No standard public benchmark exists for PR-surface injection resistance. The agent-data-injection results show why a single aggregate "prompt injection" score is misleading: defenses drove instruction injection close to zero while data injection remained effective. Corpora must cover trust metadata and serialization boundaries, not only adversarial prose.

AC.12 CI/CD Pipeline Hardening Specific to AI Augmentation

New family in the 2026 source. Two kinds of CI/CD control are in scope: those that AI augmentation newly requires, and those that AI augmentation breaks. Generic CI/CD hygiene (short-lived credentials, action pinning, branch protection, SLSA Build L3 provenance, multi-party production approval) is covered by OWASP ASVS v5 V10, the OWASP Top 10 CI/CD Security Risks, NIST SP 800-204D, and SLSA v1.2, and is assumed in place.

#RequirementLevelThreat MitigatedVerification ApproachGaps / Notes
AC.12.1Verify that workflows triggered by untrusted contributions (GitHub Actions pull_request_target, workflow_run, and equivalent fork-aware triggers in other CI systems) never check out, build, test, or otherwise execute untrusted code in a context that has repository write permissions or access to repository, organization, package-registry, cloud, or deployment secrets. Where a privileged follow-up step is needed, the untrusted contribution is first processed in an unprivileged pull_request workflow, and only validated passive artifacts are passed forward to a separate privileged workflow.1The "pwn request" class — the single most exploited CI pattern of 2024-2026: Ultralytics PyPI compromise via pull_request_target template injection and cache poisoning (December 2024, trojaned releases shipped a cryptominer); the prt-scan campaign (from March 11, 2026: 6 accounts, 500+ malicious fork PRs posing as CI updates, ~10% success rate, AWS/Cloudflare/Netlify tokens stolen, at least 2 npm packages compromised); hackerbot-claw's autonomous exploitation (February 2026, RCE in 5 of 7 targets, GITHUB_TOKEN theft from a 140k-star repo).Scan all workflows with zizmor (dangerous-triggers audit), poutine, or OpenSSF Scorecard's Dangerous-Workflow check. Manually review any pull_request_target/workflow_run usage for untrusted checkout (ref: github.event.pull_request.head.sha patterns). Verify the split-workflow pattern from GitHub Security Lab's "Preventing pwn requests" series: unprivileged pull_request processing, passive artifact handoff, separate privileged workflow. Confirm awareness of GitHub's December 8, 2025 secure-by-default change (privileged triggers anchored to default-branch workflow definitions) and that it is not relied on as the sole defense.The TOCTOU, non-default-branch, cache-poisoning, and artifact-poisoning variants documented in "pwn requests" Part 4 (January 2025) survive the platform's 2025 hardening. prt-scan showed attackers now generate language-aware payload variants with AI, so signature-based review of fork PRs is insufficient — the structural fix (no privileged execution of untrusted code, ever) is the only durable one.
AC.12.2Verify that secrets, credentials, and pipeline job tokens are not persisted into workspaces that process AI-touched or fork-originated untrusted code. For example, set persist-credentials: false on checkout where the platform supports it, and scrub CI runners of cached credentials before AI tooling runs.1Credential harvesting from runner workspaces: tj-actions/changed-files (CVE-2025-30066, March 2025) dumped CI memory — PATs, npm tokens, RSA keys — into public Actions logs across 23,000+ repos; the Nx "s1ngularity" attack (August 26, 2025) was the first supply-chain malware to weaponize victims' own AI CLIs (Claude/Gemini/Q) for reconnaissance, harvesting 2,349 secrets from 1,079 systems. An AI agent running in a credential-bearing workspace can be prompt-injected into reading exactly those files.Audit checkout steps for persist-credentials: false (zizmor's artipacked audit automates this). Verify AI tooling steps run after credential scrub or in a separate credential-free job. Check that GITHUB_TOKEN defaults to read-only contents org-wide with per-job permissions: escalation. Inventory which secrets each AI-invoking workflow can reach (grep -r 'secrets\.' across workflow definitions).The default actions/checkout behavior persists credentials, so non-compliance is the natural state of any repo that never explicitly opted out. The s1ngularity lesson extends scope: AI CLI config files (~/.claude, ~/.gemini) are themselves credentials and must not sit in workspaces processing untrusted code.
AC.12.3Verify that secrets are not exposed to workflows running code from forks or first-time contributors. Environment-protection rules (or the platform equivalent, such as protected variables and deployment approvals) require a manual approval before any secret-bearing job runs for those contributions. This control pairs with AC.11.7 and AC.13.2. Bot-level enforcement under AC.11.7 does not substitute for the platform-level enforcement required here.1Fork-PR secret exfiltration — the prt-scan campaign succeeded in roughly 10% of its 500+ attempts specifically where maintainers had loosened fork protections or used privileged triggers. AI-scaled attackers make every loosened repository a target: fork waves cost the attacker nothing.Verify GitHub's first-time-contributor workflow approval requirement is at its strictest setting ("require approval for all outside collaborators"), fork PRs receive read-only GITHUB_TOKEN and no secrets (platform default), and secret-bearing jobs sit behind environment-protection rules with required reviewers. In GitLab, confirm protected variables and deployment approvals. Test with a fork PR from a fresh account: no secret-bearing job should run without manual approval.Platform defaults are good here; the risk is configuration drift — repos that lowered approval requirements for contributor convenience. GitHub's December 2025 change also aligned environment-policy evaluation with the executing workflow version, closing an environment-rule bypass. The explicit non-substitution rule (bot gates don't replace platform gates) reflects defense-in-depth: hackerbot-claw was stopped by platform rules after reaching the bots.
AC.12.4Verify that self-hosted or persistent runners used by AI tooling are ephemeral (destroyed after each job), network-segmented, and isolated from production credentials. Persistent or long-lived runners do not process fork PRs or AI-generated untrusted artifacts under any circumstances.2Runner persistence as an attacker foothold: a prompt-injected agent or malicious fork PR executing on a long-lived runner can plant credentials harvesters, poison caches for subsequent jobs, or pivot through the runner's network position — escalating a one-shot injection into durable compromise (OWASP CICD-SEC-06).Inventory runners that execute AI tooling. Verify ephemerality (fresh VM/container per job — GitHub-hosted, or ARC/Kubernetes with single-use runners), network segmentation away from production, and absence of production credentials. Confirm routing rules prevent fork PRs and AI-generated untrusted artifacts from reaching any persistent runner. StepSecurity harden-runner (2026: agentless eBPF support for ARC and third-party runner fleets) adds egress monitoring per job.Chainguard's "principle of ephemerality" guidance frames the economics: short-lived infrastructure shrinks the attacker's window to minutes. The hard part is the intersection set — organizations often have one shared self-hosted pool for GPU or license-bound jobs, and that pool is exactly where AI tooling lands; budget for a dedicated ephemeral fleet.
AC.12.5Verify that changes to workflow definition files (.github/workflows/*, .gitlab-ci.yml, Jenkinsfile, Argo, Tekton, and equivalents) are detected on every PR and route through an elevated review path that includes a security reviewer, regardless of who the contributor is or whether AI was involved. AI agents must not be granted bypass authority over this review path.2Workflow files as the pipeline's root of trust: prt-scan's malicious PRs posed as routine CI updates precisely because workflow edits get rubber-stamped; AI coding agents also routinely propose workflow changes as part of larger diffs, where they hide in reviewer fatigue.Verify CODEOWNERS (or platform path rules) cover all workflow definition paths and require a security-team reviewer. Confirm the rule is in a ruleset agents cannot edit (ties to AC.8.3) and has no agent bypass. Sample recent workflow-file PRs for evidence the elevated path fired. Run zizmor/actionlint in CI so the security reviewer gets findings, not raw YAML.Overlaps deliberately with AC.4.4 (workflow files are in its security-critical file list) and AC.7.4 (trigger configurations) — this control adds the "regardless of contributor" universality. The practical failure mode is monorepos with hundreds of workflow files where CODEOWNERS coverage gaps go unnoticed; audit coverage with a path-matching dry run.
AC.12.6Verify that pipeline audit logs (workflow runs, secret access, runner registration, permission grants, OIDC token issuance) are streamed in real time to centralized security monitoring. Detection rules are tuned for AI-augmented threat patterns: bulk PR creation from new accounts, workflow-file modifications in fork PRs, unexpected secret access from AI-runner pools, and unusual egress (webhooks, paste sites, bin services) from AI workloads.2The detection gap that let tj-actions run for days and prt-scan for weeks: platform audit events existed but nobody was watching for the AI-era patterns. Each named detection rule maps to a real campaign — bulk PRs from new accounts (hackerbot-claw, prt-scan), workflow-file modification in fork PRs (prt-scan), unexpected secret access (tj-actions), unusual egress (s1ngularity's public-repo exfiltration).Verify audit-log streaming (GitHub Enterprise audit log streaming, GitLab audit events) into the SIEM in real time. Review detection content for the four named pattern families and confirm each has an owner and a tested alert path. Harden-runner's per-step egress correlation and Datadog-BewAIre-style LLM classification of inbound events are reference implementations for the egress and bulk-PR rules respectively.OWASP CICD-SEC-10 (Insufficient Logging and Visibility) predates AI augmentation; what is new is the rule content. False-positive tuning is genuinely hard for bulk-PR detection — Dependabot and release bots look like campaigns — so allowlist known automation identities first.
AC.12.7Verify that artifacts produced by untrusted PR workflows are treated as untrusted passive data when a privileged follow-up workflow consumes them. The privileged workflow never executes binaries, scripts, packages, caches, or generated workflow fragments that originated in an untrusted contribution.2Artifact and cache poisoning across the trust boundary — the escalation path documented in GitHub Security Lab's "pwn requests" Part 4 (January 2025) and exploited in the Ultralytics attack (GitHub Actions cache poisoning, December 2024): the unprivileged workflow writes a poisoned artifact or cache entry, and the privileged consumer executes it.Map every workflow_run-style privileged consumer of untrusted-workflow artifacts. Verify consumption is parse-and-validate only: no execution of downloaded binaries/scripts, no npm install of artifact-supplied packages, no eval of generated workflow fragments, and cache keys segregated by trust level (zizmor's cache-poisoning audit helps). Test by passing a marker script through the artifact path and confirming it is never executed.Cache segregation is the weakest link in practice: GitHub Actions caches are scoped per branch but writable from PR workflows in ways teams don't expect. The "generated workflow fragments" clause anticipates agent pipelines that template workflow YAML from upstream outputs — an emerging pattern with no scanner coverage yet.
AC.12.8Verify that the remediation of a vulnerable workflow includes invalidating or re-validating any PR that was opened before the fix landed. Without this step, a later commit to the same PR can pick up the stale workflow definition and route around the fix.2The stale-PR bypass documented in "pwn requests" Part 4: workflow fixes apply to new PRs, but pre-existing open PRs can still trigger the old vulnerable definition on their next commit — attackers deliberately park PRs before disclosure windows close. The Ultralytics attack reintroduced a previously-fixed vulnerable pattern, showing remediation regressions also go unnoticed.Review the workflow-vulnerability remediation runbook for an explicit step: enumerate open PRs predating the fix, then close/re-trigger/re-validate them. After any workflow security fix, sample open PRs to confirm they can no longer reach the vulnerable definition. Add a regression test (zizmor in CI) so the fixed pattern cannot be reintroduced silently.The most overlooked requirement in the family — no platform feature automates stale-PR invalidation, and few IR runbooks include it. GitHub's December 2025 anchoring of privileged triggers to default-branch definitions reduces (but does not eliminate) the exposure for pull_request_target; other CI systems retain the full window.

AC.13 Adversarial AI Detection in Inbound Contributions

New family in the 2026 source, and the one that flips the lens: here the AI is on the attacker's side, and the defender is trying to spot the signal in inbound contributions — AI-run fork-and-PR campaigns at scale, with malicious payloads tailored to the target repository.

#RequirementLevelThreat MitigatedVerification ApproachGaps / Notes
AC.13.1Verify that contribution-velocity and contributor-reputation analytics flag anomalies: bulk PR creation from newly created accounts, coordinated fork waves immediately preceding PRs, PR volumes that are inconsistent with human authorship, and reuse of payload patterns across unrelated repositories.1AI-scaled contribution campaigns: hackerbot-claw filed 16 PRs, 2 issues, and 8 comments across 9 high-profile repositories in roughly a week (February 21-28, 2026), iterating one payload over 18 hours; prt-scan ran 6 waves from 6 fresh accounts with 500+ fork PRs from March 11, 2026. Both exhibited every named anomaly: new accounts, fork waves, inhuman PR velocity, and cross-repository payload reuse.Verify analytics over platform events (GitHub audit log, webhook streams) compute contributor-account age, fork-to-PR timing, PR velocity per account, and payload similarity across repositories, with alerts routed to maintainers/security. Datadog's BewAIre — a production two-stage LLM pipeline that classifies inbound GitHub events as benign/malicious within seconds and caught hackerbot-claw's obfuscated payloads and issue-body injections — is the public reference implementation (March 2026).Cross-repository payload-reuse detection effectively requires ecosystem-level visibility that single organizations lack; vendor threat-intel feeds and platform-level detection partially fill the gap. Velocity heuristics alone misfire on legitimate automation — combine with reputation and content signals.
AC.13.2Verify that PRs from first-time or low-reputation contributors require maintainer approval before any privileged workflow processes them. Privileged workflows here include AI review bots, secret-bearing jobs, and external-integration calls.1Attackers spending fresh accounts as ammunition: every 2026 campaign used newly-created or low-history accounts because accounts are free and bans are costless. Without a reputation gate, each new account gets one free shot at the privileged pipeline — including the AI review bot, which AC.11.7 shadow mode only partially de-fangs.Confirm GitHub's "require approval for first-time contributors" (or the stricter all-outside-collaborators setting) is enforced org-wide, and that the privileged-workflow definition explicitly includes AI review bots and external integrations, not just secret-bearing jobs. Test with a fresh-account fork PR: nothing privileged should fire pre-approval.The platform gate (GitHub, since 2021) covers workflow runs but not all bot surfaces — GitHub App-driven review bots triggered by webhooks bypass Actions approval entirely and need their own reputation check (community pressure for stronger platform gating is ongoing). "Low-reputation" beyond first-time is undefined by platforms; organizations approximate with account age and prior-merge thresholds.
AC.13.3Verify that automated PR pipeline gates detect known indicators of LLM-generated or LLM-assisted malicious payload patterns: registry-confusable or typosquatted dependency names, package references that do not resolve to any published version, and dependencies whose creation, first-publication, or maintainer-change timestamps look anomalous relative to the PR.2Slopsquatting and dependency-chain abuse: the USENIX Security 2025 study (16 models, 576k samples) found ~20% of generated code samples recommended non-existent packages; attackers register the hallucinated names. Aikido observed live agents installing the hallucinated react-codeshift npm package in January 2026. DepDec-Bench adds a second failure mode: agents select known-vulnerable dependency versions more often than humans even when the package exists.Verify PR gates resolve every added dependency against the registry (non-resolving names block), check name-confusability against popular packages, and pull registry metadata for creation/first-publication/maintainer-change timestamps relative to the PR date. Add a "safe version decision" check for AI-authored dependency changes: no known-vulnerable version at PR time, no unnecessary new package where an approved dependency already exists, and no unexplained downgrade. Tools: Socket, OpenSSF Package Analysis-class scanners, Snyk's slopsquatting guidance; OWASP CICD-SEC-03 (Dependency Chain Abuse) is the framework anchor.Timestamp-anomaly detection and safe-version scoring are the least standardized parts — no common off-the-shelf gate scores "package created two days before the PR referencing it" or "agent picked a vulnerable version despite a patched alternative." Hallucination rates differ sharply by model class (commercial ~5.2% vs open-source ~21.7% on average), so organizations running local models inherit more of this risk.
AC.13.4Verify that detection rules are tagged to MITRE ATT&CK (T1195 Supply Chain Compromise and CI/CD-relevant sub-techniques) and to MITRE ATLAS techniques, maintained for the inbound contribution analysis use case, and reviewed against current threat intelligence.2Detection content rotting into incoherence: untagged ad-hoc rules cannot be coverage-mapped, so nobody notices the campaign class with zero rules until it lands. Framework tagging also enables purple-team validation against the 2025-2026 campaign corpus (tj-actions, prt-scan, hackerbot-claw, s1ngularity).Sample the detection rule set: each rule carries ATT&CK (T1195.x and CI/CD-relevant techniques) and/or ATLAS technique tags, an owner, and a last-reviewed date. Verify a recurring threat-intel review updates rules against current campaigns, and that coverage maps show which technique classes have no detection.ATLAS coverage for attacker-side-AI techniques (AI-generated payloads, AI-run contribution campaigns) is still thinner than defender-side coverage — expect mapping gaps and document them rather than forcing bad fits. This is detection-engineering hygiene applied to a new domain; the practice is mature, the content is not.
AC.13.5Verify that confirmed or high-confidence adversarial contributions trigger automated containment: block the PR, quarantine the fork, suspend the contributor, notify maintainers, and freeze affected workflow files. Triage decisions feed back into detection tuning.3Human-speed response losing to machine-speed attack: prt-scan's waves landed faster than maintainer triage cycles, and hackerbot-claw iterated payloads over hours. Manual containment means the campaign's later waves succeed where the first was noticed.Review the automated containment playbook and its triggers: PR block, fork quarantine, contributor suspension, maintainer notification, and workflow-file freeze. Test in staging with a synthetic high-confidence detection and time the containment chain. Verify a feedback loop records triage outcomes (true/false positive) into detection tuning.Auto-suspension of contributors carries real false-positive cost in open source — Datadog's BewAIre runs human-confirmed blocking for exactly this reason. Workflow-file freezing has no native platform primitive; implementations approximate with emergency rulesets. The maturity bar (Level 3) reflects that most organizations should build reliable detection (AC.13.1-13.3) before automating response.
AC.13.6Verify that PR analytics include structural AST profiling and stylometric or entropy-based heuristics tuned to identify LLM-generated code patterns. Detection in this category is still maturing, so compensating controls are accepted in place of high-precision automated detection: mandatory human review on flagged PRs, sandboxed execution of suspect payloads, and deferred merge until additional signals accrue.3Disguised AI-generated contributions: attackers strip obvious AI markers, and Georgia Tech's CVE-attribution work estimates 5-10x undercounting because origin signals are removed. The curl project's experience quantifies the noise side — ~20% of its 2025 bug-bounty submissions were AI slop, driving its valid-report rate under 5% and the program's closure on January 31, 2026.Review whether PR analytics incorporate stylometric features (line/blank-line/comment ratios, cyclomatic complexity — the "I Know Which LLM Wrote Your Code Last Summer" feature set, 2025), AST-structural profiling, or entropy heuristics, and what happens on a flag: mandatory human review, sandboxed execution, or deferred merge. Confirm the compensating controls exist even where automated detection does not.The source text itself concedes this is research-edge — SemEval-2026 Task 13 is formalizing machine-generated code detection benchmarks, but production-grade tooling does not exist. Simple compensating controls work today: Ghostty's contributor-history-based LOC gating (2026) is a working example of cheap structural friction against slop PRs. Detection will also misfire on legitimate AI-assisted contributions, which are now the majority in many projects — the goal is routing to scrutiny, not blocking AI authorship per se.

AC.14 Compromise Containment & Automated Remediation

New family in the 2026 source. When an AI-adjacent compromise — a prompt-injected bot, a leaked CI secret, a malicious AI-generated artifact in a build — is suspected or confirmed, the goal is to contain the damage and shorten recovery.

#RequirementLevelThreat MitigatedVerification ApproachGaps / Notes
AC.14.1Verify that an incident-response playbook exists for AI-in-pipeline compromise. At minimum it covers: revoking AI-agent credentials, rotating every secret that touched the compromised workflow run, quarantining the compromised artifacts, notifying downstream consumers, notifying regulators where applicable, and preserving prompts, responses, and audit logs for forensics.1Improvised response to a novel incident class: agentic incidents cascade across thousands of workflow runs before the first alert, and conventional IR playbooks have no step for "the reviewer bot was prompt-injected." The s1ngularity response showed the required scope — GitHub PATs/OAuth, npm tokens, cloud keys, and AI-provider keys all needed rotation, plus hunting for attacker-created exfiltration repos.Review the playbook for all six named elements. Confirm prompt/response/audit-log preservation points at the AC.5.3/AC.11.6 tamper-evident stores (forensics needs the injected context, not just the actions). Check the regulator-notification step maps to applicable regimes (EU AI Act serious-incident reporting for high-risk deployments, sectoral breach rules). CSA's Comment-and-Control mitigation note (April 17, 2026) and Microsoft's prompt-abuse detection guidance (March 12, 2026) are useful drafting references.Published AI-in-pipeline IR playbooks only began appearing in 2026 and remain immature — most organizations adapt their CI/CD-compromise runbook (post-tj-actions vintage) by adding agent-credential and prompt-forensics steps. The hardest drafting question is triggering: "suspected prompt injection" lacks the crisp indicators that traditional IR triggers have.
AC.14.2Verify that any secret that touched a workflow run associated with a suspicious PR, a prompt-injection event, or an AI-agent anomaly is automatically rotated, and that downstream issuers (cloud IAM, package registries, signing-key custodians) are notified of the rotation.1The window between exposure and rotation: tj-actions dumped secrets into public logs where anyone could copy them — by the time humans triaged (CISA alert March 18, 2025, six days after onset), exposure was total. prt-scan exfiltrated cloud tokens that remained valid until manually rotated.Verify automation maps workflow runs to the secrets they could read (the grep -r 'secrets\.' inventory, maintained continuously) and that the named trigger events fire rotation without human latency. Confirm downstream-issuer notification (cloud IAM, package registries, signing-key custodians) is in the automation, not a manual afterthought. HashiCorp Vault/HCP auto-rotation with overlapping active versions provides zero-downtime mechanics; the durable fix is OIDC-issued short-lived credentials that expire in minutes and need no rotation at all.Auto-rotation can self-DoS production if consumers cache credentials — the overlapping-version pattern mitigates this but requires consumer discipline. Signing-key rotation is the gap: rotating a cosign/Sigstore identity invalidates verification policies downstream, and few playbooks handle re-attestation of artifacts signed during the exposure window.
AC.14.3Verify that AI agent identities (keys, tokens, OIDC trust grants) can be rapidly revoked and quarantined, with a target time-to-revoke that is written down and tested at least once a year.2A compromised or prompt-injected agent continuing to act while humans deliberate: agent identities often span systems (SCM, CI, cloud, model APIs), and partial revocation leaves the attacker the remainder. The 2026 incident tempo — hackerbot-claw iterating payloads over 18 hours — sets the realistic response clock.Inventory every credential class per agent identity: API keys, GitHub App installations, OIDC trust grants, model-provider keys. Verify a single revocation procedure covers all of them (kill switch, not scavenger hunt), the target time-to-revoke is documented, and an annual test exercises it with the timing recorded. AISVS C9.4 (agent identity handling) and NIST SP 800-207 zero-trust principles are the framework anchors.OIDC trust-grant revocation is the subtle one: deleting a cloud role's trust policy entry is fast, but cached/issued tokens live until expiry — which is why AC.8.2's short-lived-token preference is also a containment control. Few organizations test agent revocation at all; the annual-test clause is the audit hook.
AC.14.4Verify that build provenance and AI BOM records are used during incident response to identify every downstream artifact produced under the suspect AI agent or the compromised pipeline run, so that recall, rebuild, or quarantine can be targeted.2Unscoped blast radius: without provenance, "what did the compromised agent touch?" is answered by rebuilding everything or hoping. The Ultralytics incident required identifying exactly which PyPI releases (8.3.41-8.3.46) were trojaned; provenance-driven scoping is what makes such answers fast and defensible.Run a tabletop query: given a suspect agent identity and time window, can the team enumerate every downstream artifact via SLSA provenance attestations, in-toto metadata, and AI-BOM/ML-BOM records (CycloneDX)? Verify recall/rebuild/quarantine actions key off that enumeration. Sigstore/cosign verify-attestation plus a queryable attestation store (Rekor or registry-attached) is the practical stack; OWASP's CycloneDX AI/ML-BOM guide covers the record format.This is where AC.9/AC.10 investments pay off — organizations without signed provenance simply cannot satisfy it. The OWASP framing is blunt: without an AI-BOM you cannot scope an AI supply-chain incident. Cross-system joins (provenance store ↔ registry ↔ deploy inventory) are the engineering cost nobody budgets for.
AC.14.5Verify that automated remediation is tested in tabletop or live-fire exercises at least once a year. The scenarios include a prompt-injected reviewer bot, fork-PR secret exfiltration, and an AI-generated malicious workflow file.3Untested automation failing during a real incident — rotation scripts with stale credentials, revocation paths missing a system, containment that breaks the build farm. Each mandated scenario replays a real 2025-2026 incident class: Comment-and-Control (injected reviewer bot), prt-scan/tj-actions (fork-PR exfiltration), Ultralytics/prt-scan (malicious workflow file).Review exercise records for the past year: at least one tabletop or live-fire run covering all three named scenarios, with measured outcomes (time-to-detect, time-to-revoke, time-to-rotate) and remediation items tracked to closure. Live-fire in a staging org — synthetic secrets, a sacrificial repo, a deliberately injected staging bot — gives far higher assurance than tabletop.The three scenarios double as a maturity test of every prior family: the exercise fails informatively wherever AC.11 logging, AC.12 gates, or AC.14.2 rotation are weak. Public exercise templates for AI-in-pipeline scenarios do not exist yet; the published incident post-mortems (Datadog's hackerbot-claw account, Wiz's prt-scan and s1ngularity write-ups) are the best available scenario scripts.

Threat Landscape

  • AI-generated code introducing subtle vulnerabilities (SQL injection, XSS, insecure defaults) -- 25.7% overall vulnerability rate (2026 data)
  • Prompt injection through repository context (malicious CLAUDE.md, .cursorrules files) -- demonstrated as practical attack vector by Pillar Security (2025)
  • Over-reliance on AI-generated code without human review -- the "trust gap" is the primary risk amplifier; developers review AI output less carefully
  • Leaked secrets or PII in prompts sent to cloud-hosted coding assistants
  • AI-generated infrastructure-as-code with insecure defaults (overly permissive IAM, public S3, open security groups)
  • Package hallucination: AI models suggest non-existent packages that attackers register (Lanyado, Vulcan Cyber, 2023)
  • Autonomous agents with excessive permissions bypassing change control
  • Supply-chain attacks via compromised IDE extensions
  • Direct exploitation of AI coding tools: CVE-2025-62453 (improper output validation), CVE-2025-53773 (config file manipulation leading to RCE)
  • Jailbreak attacks on coding assistants: "affirmation jailbreak" bypasses safety filters with simple agreeing words
  • SSRF (CWE-918) as dominant AI-generated vulnerability: most frequent single weakness in 2026 benchmarks, surpassing traditional injection categories
  • AI code review tool limitations: Copilot Code Review failed to flag OWASP Top 10 in controlled testing; cannot reason about cross-function data flow
  • [New] IDEsaster disclosure (December 2025): 30+ vulnerabilities across 8 AI IDEs (Cursor, Windsurf, Copilot, Zed, Roo Code, Kiro, JetBrains Junie, Claude Code); 24 CVEs assigned. Attack patterns include prompt injection, auto-approved tool calls, and configuration file weaponization.
  • [New] Claude Code CVEs (February 2026): CVE-2025-59536 (CVSS 8.7, RCE via MCP config) and CVE-2026-21852 (CVSS 5.3, API key exfiltration via malicious repo). Demonstrated that opening an untrusted repository is sufficient for exploitation.
  • [New] AI coding agents fail at access control: DryRun Security testing (March 2026) found 87% of PRs from Claude Code, Codex, and Gemini contained vulnerabilities — broken access control was universal, and pattern-based SAST caught only 12% of issues.
  • [New] Shadow AI risk quantified: ISACA framework (2026) reports 38% of workers admit sharing confidential information with AI tools; discovery sweeps typically find 15-20% of tools need blocking.
  • [New] AI-generated code CVE tracking (Georgia Tech, March 2026): 35 new CVEs in March alone (27 from Claude Code, 4 from Copilot, 2 from Devin); 74 total since May 2025. Actual count estimated 5-10x higher due to stripped AI signals. CVE-2025-55526 (directory traversal, CVSS 9.1) is a confirmed example.
  • [New] Meta AI agent Sev-1 incident (March 2026): an autonomous AI agent posted unauthorized guidance on an internal forum; an employee followed the advice, triggering a privilege escalation chain that exposed sensitive data to unauthorized engineers. Demonstrates the real-world consequences of missing agent change controls (AC.8) and audit trails (AC.10).
  • [New] OpenClaw supply chain attack (March 2026): 1,184 malicious skills discovered in ClawHub, the package registry for the OpenClaw AI agent framework — roughly one in five packages. Largest confirmed supply chain attack targeting AI agent infrastructure to date.
  • [New] EU AI Act Article 50 transparency obligations enforceable August 2, 2026: requires machine-readable disclosure of AI-generated content origin. Draft Code of Practice (second draft, March 2026; final expected June 2026) names C2PA metadata as the preferred machine-readable provenance format and W3C PROV as the cross-modal standard for code and text. Non-compliance penalties: up to €15M or 3% of worldwide turnover.
  • [New] Veracode Spring 2026 GenAI Code Security Update (150+ LLMs): security pass rate flat at ~55% despite two years of "revolutionary" model releases. Java worst at 29% pass rate; XSS (15%) and Log Injection (13%) remain catastrophic weaknesses. OpenAI's reasoning-focused models are the first to meaningfully break the ceiling at 70-72%.
  • [New] Georgia Tech Vibe Security Radar (April 2026 update): 74 confirmed CVEs attributed to AI-generated code; growth curve accelerated from ~18 cases across seven months (H2 2025) to 56 cases in Q1 2026, with 35 CVEs in March 2026 alone (exceeding the entire 2025 total). Team is developing behavioral detection (variable naming, function structure, error-handling stylistic patterns) to catch AI-generated code when signatures are stripped.
  • [New] Claude Code markdown prompt injection (April 3, 2026): new disclosure showing markdown files pulled from GitHub (READMEs, issue bodies, PR descriptions) can carry prompt injections that steer the agent into unintended actions. Expands the "config file weaponization" pattern to all ingested content types.
  • [New] Agent Commander research (Embrace The Red, March 2026): prompt injection into AI coding agents demonstrated as persistent command-and-control. Autonomous agents can be converted into remotely-controlled malware delivery platforms — every ingested artifact (repo files, issues, PR bodies, markdown) is now an adversarial instruction surface.
  • [New] Snyk ToxicSkills audit (February 2026): of 3,984 agent skills reviewed, 13.4% (534) contain critical-level security issues and 36.82% (1,467) contain at least one flaw. 91% of confirmed malicious skills combine prompt injection with code-level attacks (credential exfiltration, malware download, safety disablement). Named threat actors: zaycv (40+ malware skills), Aslaep123 (crypto-credential theft), aztr0nutzs (pre-deployment malicious skill repo). Koi Security independently found 341 malicious entries in 2,857 skills (12%).
  • [New] Comment and Control (April 2026): Aonan Guan and Johns Hopkins collaborators showed that PR titles, issue bodies, and comments can become prompt-injection carriers for AI coding agents in GitHub Actions, with secrets exposed through comments, logs, or commits when privileged tools and untrusted SDLC text share the same runtime.
  • [New] Formal-verification evidence (April 2026): Broken by Default used SMT-backed analysis over 3,500 generated artifacts and reported exploitable findings that ordinary scanners often missed, strengthening the case for AC.4.4 fuzz/property tests and manual review on security-critical code.
  • [New] Cursor CVE-2026-26268 (CVSS 9.9, April 2026): a malicious repository containing an embedded bare repo with a pre-commit hook achieves arbitrary code execution as soon as the Cursor AI agent runs Git commands — no user prompt, no sandbox enforcement. Patched in Cursor 2.5. Demonstrates that AI agents executing Git on untrusted repositories make Git hooks an auto-approved RCE primitive.
  • [New] Claude Code SOCKS5 sandbox bypass (silently patched April 1, 2026 in v2.1.90; second bypass disclosed May 2026 by Aonan Guan): a SOCKS5 hostname null-byte injection let hostile workspaces exfiltrate AWS credentials, GitHub tokens, internal endpoints, and model API keys via raw SOCKS5, bypassing HTTP egress logging. Spanned ~130 versions over 5.5 months with no public advisory or CVE issued through mid-May 2026.
  • [New] Microsoft Semantic Kernel CVE-2026-25592 (CVSS 9.9) and CVE-2026-26030 (May 7, 2026, "When prompts become shells"): path traversal in SessionsPythonPlugin and eval()-based lambda filters in InMemoryVectorStore turn a single prompt into host RCE. Patched in semantic-kernel 1.39.4 (Python) and 1.71.0 (.NET). Generalises the lesson that any agent-callable tool touching the filesystem, an interpreter, or an evaluator must be hardened to internet-grade input.
  • [New] AutoJack (Microsoft, June 18, 2026): untrusted web content rendered by an AutoGen browsing agent could reach a localhost MCP WebSocket and spawn arbitrary processes through URL-supplied StdioServerParams. Fixed before the affected MCP WebSocket surface reached PyPI, but it shows that localhost control planes, MCP bridges, and debug endpoints are reachable attack surface once an agent can browse untrusted content.
  • [New] Apiiro Fortune 50 Deep Code Analysis study (September 2025): AI-assisted developers produce 3-4x more commits but introduce security findings at 10x the rate. Privilege-escalation paths +322%, architectural design flaws +153%. By June 2025, participating organisations were absorbing 10,000+ new AI-attributed findings per month. Reinforced by CSA's April 2026 research note "Vibe Coding's Security Debt: The AI-Generated CVE Surge".
  • [New] AI-authored technical debt in the wild (April 2026 revision): across 302.6k verified AI-authored commits in 6,299 repositories, researchers attributed 484,366 issues to AI commits; more than 15% of commits from every studied assistant introduced at least one issue, and 22.7% of tracked AI-introduced issues survived to the latest revision.
  • [New] Agent dependency choices have measurable security drag (DepDec-Bench, January 2026): coding agents selected PR-time known-vulnerable dependency versions 2.46% of the time and showed a net-negative security impact, while human-authored dependency changes showed a net-positive impact. Treat agent-authored version bumps, new packages, and downgrades as review triggers.
  • [New] OWASP Top 10 for Agentic Applications 2026: a separate framework from the LLM Top 10, focused on goal misalignment, tool misuse, delegated trust, inter-agent communication, persistent memory poisoning, cross-context injection, and emergent autonomous behaviour. Introduces a Least-Agency principle that maps directly onto AC.8 (Autonomous Agent Change Control Constraints) for AI coding agents.
  • [New] CodeRabbit production RCE (disclosed August 2025): Kudelski Security achieved remote code execution on the AI review bot's production servers via a malicious .rubocop.yml loaded from a PR, exposing the GitHub App private key with read/write access to 1M+ repositories plus Anthropic/OpenAI API keys. The canonical AC.11 incident: the bot's own tool-config loading path, not its prompt, was the injection vector.
  • [New] CamoLeak (CVSS 9.6, disclosed October 2025): invisible markdown comments in PR descriptions made GitHub Copilot Chat exfiltrate private-repository secrets and source by encoding them into pre-signed GitHub Camo image URLs — a CSP bypass through GitHub's own proxy. Patched August 14, 2025 by disabling image rendering.
  • [New] hackerbot-claw autonomous attack campaign (February 21-28, 2026): an AI agent self-described as Claude-powered ran a fork-and-PR exploitation campaign against Microsoft, Datadog, Aqua, and CNCF repositories — 16 PRs across 9 repos, RCE in 5 of 7 targets, GITHUB_TOKEN theft from the 140k-star awesome-go repo, a payload iterated over 18 hours, and a prompt-injection attempt against Datadog's LLM review workflow. Stopped at Datadog by layered platform controls (deny-by-default Actions tokens, rulesets) and the model's own injection refusal.
  • [New] prt-scan campaign (from March 11, 2026): six fresh GitHub accounts pushed 500+ malicious fork PRs posing as routine CI updates, exploiting pull_request_target-class triggers at ~10% success; payloads evolved into AI-generated language-aware variants; AWS keys, Cloudflare and Netlify tokens stolen with exfiltration routed only through the GitHub API and cloud metadata endpoints to evade egress detection. At least two npm packages compromised downstream.
  • [New] tj-actions/changed-files supply chain attack (CVE-2025-30066, CVSS 8.6, March 12-15, 2025): a compromised bot PAT injected a memory-scraping payload that dumped CI secrets into public Actions logs across 23,000+ repositories; began as a targeted attack on Coinbase; CISA alert March 18, 2025. Paired with reviewdog/action-setup (CVE-2025-30154).
  • [New] Nx "s1ngularity" npm compromise (August 26, 2025): the first supply-chain malware to weaponize victims' own AI CLI tools — malicious Nx versions invoked locally installed Claude/Gemini/Q CLIs for reconnaissance and harvested their config/auth tokens; 2,349 secrets from 1,079 systems exfiltrated to 1,400+ attacker-created public GitHub repos.
  • [New] curl ends its bug bounty (January 31, 2026): ~20% of 2025 submissions were AI slop, the valid-vulnerability rate fell from a historical 15%+ to under 5%, and the project shut the HackerOne program after 87 confirmed vulnerabilities and ~$100k paid — the clearest public quantification of attacker/grifter-side AI noise that AC.13 controls address.
  • [New] Slopsquatting quantified (USENIX Security 2025; live exploitation January 2026): across 16 models and 576k samples, ~20% of generated code samples recommended non-existent packages (commercial models ~5.2%, open-source ~21.7% average); Aikido observed live agents installing the hallucinated react-codeshift npm package registered by attackers. 8.7% of hallucinated Python package names exist on npm, enabling cross-ecosystem confusion.
  • [New] Agent skill registries are semantic supply chains (April-May 2026): DDIPE research generated 1,070 adversarial skills and achieved 11.6-33.5% bypass rates by embedding payloads in documentation examples and templates; separate SKILL.md-only research showed short textual triggers can boost adversarial skill visibility to 80% Top-10 placement and description-only framing can bias selection in 77.6% of paired trials. Scan skill prose, examples, and metadata as operational input.
  • [New] GitHub secure-by-default hardening (effective December 8, 2025): pull_request_target workflows are now anchored to default-branch workflow definitions, killing the classic pwn-request variant, and environment-policy evaluation was aligned with the executing workflow version. TOCTOU, non-default-branch, cache-poisoning, and artifact-poisoning variants from GitHub Security Lab's "pwn requests" Part 4 (January 2025) remain live.

Tooling & Implementation

  • Coding assistants: GitHub Copilot, Cursor, Claude Code, Amazon Q Developer, Windsurf
  • AI code review: GitHub Copilot Code Review (GA Apr 2025; CodeQL integration Oct 2025), CodeRabbit (2M+ repos), Aegis (AI-code-specialized), Qodo (formerly CodiumAI), DryRun Security (contextual code review for AI agents), Anthropic Claude Code Security (limited research preview Feb 2026, embedded in Claude Code on the web; Opus 4.6-backed reasoning over codebases with self-critique to suppress false positives)
  • Code scanning: Semgrep (including Multimodal, launched March 2026), CodeQL, Snyk Code, SonarQube, Aikido Security, Checkmarx — note: single-tool coverage catches under 22% of AI-generated vulnerabilities (AppSec Santa 2026), so run multiple scanners. Semgrep Multimodal combines LLM reasoning with rule-based SAST for business logic flaws. AI-driven SAST reports average 68% false-positive reduction in 2026 data.
  • Merge blocking: GitHub code scanning merge protection, required status checks, GitLab security approvals, and equivalent CI quality gates. The key control is enforcement, not just report generation: critical/high findings should block until fixed or explicitly risk-accepted by an authorized reviewer.
  • IaC scanning: Checkov, tfsec, KICS, Bridgecrew
  • Agent skill / MCP scanning: mcp-scan (open-source), Snyk Evo AI-SPM (general availability March 23, 2026; agent-scoped enforcement architecture covering install through production action), Agent Guard (Cursor integration) — essential after the ClawHub/ToxicSkills findings showed 36.82% of audited skills contain security flaws. Add semantic review of SKILL.md descriptions, examples, and templates: recent research shows registry discovery, selection, and governance can be manipulated by metadata alone, while DDIPE payloads hide in examples that agents later reuse.
  • Prompt mediation / agent-callable security: Apiiro CLI (April 9, 2026) intercepts and rewrites prompts to Copilot, Cursor, and Claude Code using Deep Code Analysis context, and ships six agent skills that Claude Code or Cursor can call autonomously for scanning, remediation, AI threat modeling, and prompt enrichment.
  • Provenance & origin tracking: Internal artifact manifests, signed metadata, SLSA v1.2 attestations (approved November 2025; Build Track L2 achievable via GitHub built-in support, and the newly approved Source Track L1-L4 covers authorship/review controls with source VSAs — L4 mandates two-party review with documented exceptions for trusted robots), Sigstore/cosign v3.x (keyless signing; verify-attestation consumes in-toto attestations and source VSAs), in-toto Attestation Framework (ITE-6), AIBOM via CycloneDX extension (aibom-toolkit), C2PA machine-readable metadata (named in EU Code of Practice for AI transparency), W3C PROV (cross-modal standard for code/text provenance), EU AI Act Provenance Certificates (Draft Code of Practice, March 2026)
  • CI/CD workflow auditing (AC.12): zizmor v1.25+ (May 2026; 39+ audits including dangerous-triggers, artipacked persisted-credential detection, template-injection, cache-poisoning, unpinned-uses; parser hardened with Trail of Bits May 2026), poutine (BoostSecurity; pwn-request and transitive-unpinning detection, plus an MCP server since October 2025 so coding agents validate agent-generated CI/CD YAML before commit), actionlint (untrusted-input expression linting), OpenSSF Scorecard (Dangerous-Workflow, Token-Permissions, Pinned-Dependencies checks) and Allstar (continuous branch-protection enforcement)
  • Runner egress monitoring & ephemerality (AC.12, AC.14): StepSecurity harden-runner (eBPF egress monitoring and default-deny egress-policy: block with allowlists; 2026 support for ARC/Kubernetes and third-party runner fleets), ephemeral single-use runners, Chainguard "principle of ephemerality" guidance
  • AI bot guardrails (AC.11): LlamaFirewall (Meta, open source: PromptGuard 2 injection classifier, Agent Alignment Checks, CodeShield output scanning), Llama Prompt Guard 2 (86M/22M classifiers for screening PR/issue content pre-prompt), OPA as the policy decision point for agent privileged actions, JSON Schema / Guardrails AI for structured-output enforcement, localhost/MCP control-plane authentication, and executable allowlists for agent-launched MCP servers
  • Platform agent controls (AC.11, AC.12): GitHub Copilot cloud agent firewall (on by default; org-level allowlist management since April 3, 2026), Agent HQ sandboxed multi-vendor agent execution (GA wave February 2026), GitHub first-time-contributor workflow approval, environment protection rules, persist-credentials: false, December 8, 2025 secure-by-default pull_request_target anchoring
  • Inbound contribution analytics (AC.13): Datadog BewAIre-style two-stage LLM classification of GitHub events (production reference, March 2026), Socket / OpenSSF Package Analysis-class dependency gates for slopsquatting, contribution-velocity and account-reputation heuristics, Ghostty's contributor-history LOC gating as lightweight slop friction
  • Sandbox testing: CI/CD gates for AI-generated code, pre-commit hooks
  • Secret detection & rotation (AC.3, AC.14): detect-secrets, gitleaks, TruffleHog; HashiCorp Vault/HCP auto-rotation with overlapping active versions; OIDC-issued short-lived credentials replacing long-lived repo secrets; confidential-computing options (Intel TDX, AMD SEV-SNP, ARM CCA, NVIDIA H100 CC) for high-sensitivity agent workloads where remote attestation is needed before tool or peer-agent secret exchange
  • Property/fuzz testing: Hypothesis, fast-check, AFL, libFuzzer
  • Policy-as-code: OPA/Rego, HashiCorp Sentinel
  • Security benchmarks for code LLMs: CyberSecEval (Meta), SecurityEval, SVEN, AppSec Santa AI Code Security Benchmark
  • Secure instruction guides: OpenSSF Security-Focused Guide for AI Code Assistant Instructions — covers secure defaults, supply chain safety, language-specific guidance
  • Assessment frameworks: ISACA AI Coding Assistant Vulnerability Framework (2026) — four-phase discovery, classification, controls, monitoring
  • Standards: NIST SP 800-218A (Secure Software Development for Generative AI); NIST AI Agent Standards Initiative (February 2026) — CAISI received 937 RFI responses by the March 9, 2026 deadline, and NIST's May 18 summary says commenters broadly agreed agents create novel threats that require adapted cybersecurity practices, implementation guidance, information sharing, and standards work; ISO 42001; EU AI Act Article 12 (high-risk system logging, 6-month minimum retention); EU AI Act Article 50 transparency obligations (August 2, 2026 enforcement; timing unchanged by the Digital Omnibus); European Commission's draft Article 50 implementation guidelines (published May 8, 2026; targeted consultation through June 3, 2026; explicitly recognises that "no single active marking technique suffices" and recommends a multi-layered approach using C2PA metadata plus contextual disclosure); OWASP Top 10 for Agentic Applications 2026, OWASP State of Agentic AI Security and Governance 2.01 (June 1, 2026), and the OWASP AIUC-1 crosswalk (May 25, 2026) for mapping agent identity, runtime containment, architectural monitoring, supply-chain attestation, and schema-control gaps.

Open Research Questions

  • What percentage of AI-generated code contains security vulnerabilities in practice? Answered (April 2026 update): ~25% overall per AppSec Santa (522-sample, 6 models). Veracode Spring 2026 across 150+ models puts the security-pass rate at ~55% (so ~45% of samples fail at least one OWASP Top 10 category). Java is the worst language (29% pass), XSS (15%) and Log Injection (13%) the worst categories. Reasoning-focused models are the first to hit 70-72%.
  • How should organizations track and audit AI-generated vs. human-written code? Git metadata and commit tags remain the most practical approach, but no standard has emerged.
  • What constitutes adequate review of AI-generated infrastructure-as-code?
  • How do autonomous coding agents change the threat model for SDLC security? Prompt injection via repository context files is now a demonstrated attack vector.
  • How effective are current SAST tools at detecting AI-specific vulnerability patterns? Partially answered (2026): 78% of vulnerabilities caught by only one tool; no single scanner is sufficient. SSRF (CWE-918) is now the top AI-generated vulnerability but is poorly covered by many SAST tools.
  • What is the optimal human review depth for high-volume AI-generated code? Copilot generates ~46% of code where enabled; Copilot Code Review failed to flag OWASP Top 10 in testing, so human review remains essential.
  • How should AI coding tool CVEs (e.g., CVE-2025-62453, CVE-2025-53773, CVE-2026-21852) be tracked and managed differently from traditional software CVEs? The IDEsaster disclosure (24 CVEs across 8 IDEs) suggests the attack surface is broader than initially expected.
  • Can AI code review tools be made to reason about cross-function and cross-file data flow? Partially answered (March 2026): Semgrep Multimodal combines LLM reasoning with rule-based analysis, claiming 8x more true positives for logic flaws. DryRun Security's contextual analysis caught 88% of AI agent vulnerabilities vs. 12% for pattern-based SAST. Early results are promising but independent validation is pending.
  • What is the security impact of prompt injection attacks via repository context files (.cursorrules, CLAUDE.md) at scale? Check Point's Claude Code research (February 2026) demonstrated practical exploitation; IDEsaster showed this is not tool-specific.
  • [New] How should organizations implement the NIST AI Agent Standards Initiative (February 2026) for AI coding agents that operate autonomously in CI/CD pipelines?
  • [New] What is the optimal combination of pattern-based SAST and contextual/LLM-powered analysis for AI-generated code? Early data (12% vs. 88% detection rates) suggests fundamental rethinking of scanner strategy is needed.
  • [New] How should organizations implement AI-generated code origin tracking at scale? Georgia Tech's CVE attribution research (74 confirmed CVEs, estimated 5-10x more with stripped signals) suggests current metadata practices are inadequate.
  • [New] What is the appropriate level of AIBOM granularity for AI-generated code artifacts? The AIBOM framework proposes tracking model identity, training data lineage, and execution context, but the cost-benefit tradeoff for code (vs. model) artifacts is unclear.
  • [New] How should organizations respond to the OpenClaw-class supply chain attacks on AI agent ecosystems? Traditional package security (pinning, scanning) may be insufficient when one in five packages in a registry is malicious.
  • [New] How should organizations verify that vendor-managed network sandboxes for AI coding tools actually enforce egress allowlists, given that Claude Code shipped a SOCKS5 bypass in production for 5.5 months without an advisory? Independent red-team testing of sandboxes — not vendor self-attestation — appears necessary, but no standard test harness exists.
  • [New] What is the right cadence for re-evaluating AI coding tools (AC.2.4) when critical CVEs in major tools are now disclosed roughly monthly? Annual review is clearly inadequate, but continuous re-evaluation is operationally heavy.
  • [New] Can a standardized indirect-prompt-injection corpus for SDLC surfaces (PRs, issues, comments) emerge, so AC.2.3/AC.6.3/AC.11.8 testing is comparable across tools? Today every organization seeds its own harness from published incident payloads.
  • [New] How should the vendor non-disclosure pattern be handled in risk assessments? None of the three Comment-and-Control agent flaws received CVEs, and Claude Code's sandbox bypass was silently patched — the CVE system is systematically under-representing AI-agent vulnerability classes.
  • [New] Can LLM-generated-code detection (AC.13.6) reach production precision, or will compensating controls (reputation gates, sandboxed execution, deferred merge) remain the durable answer? SemEval-2026 Task 13 should produce the first comparable benchmarks.
  • [New] What does provenance-driven incident response (AC.14.4) cost at scale? Cross-system joins between attestation stores, registries, and deploy inventories are unbudgeted engineering in most organizations, and no reference architecture exists.
  • [New] How should coding-agent sandboxes prove that localhost control planes are not reachable from browsing agents? AutoJack shows why egress allowlists are incomplete unless loopback/MCP/debug endpoints are authenticated, authorized, and separately isolated.
  • [New] Can agent-skill registries review natural-language metadata with the same rigor as executable package code? Current research shows malicious behavior can be hidden in descriptions, examples, and templates that agents later turn into actions.

References (2024-2026 Research)

Community Notes

Discussion about AI-assisted coding security practices.


  • C02-01 Prompt Injection Defense — companion controls for treating repository text, tool inputs, and agent context as adversarial instruction surfaces.
  • C09-03 Component Isolation & Tool Authorization — complements the AC.3 and AC.8 guidance by isolating agent data flows and enforcing origin-aware tool use.
  • C10 MCP Security (hub) — maps the MCP bridge, schema validation, authentication, and secure-transport concerns that show up in AutoJack and agent skill ecosystems.
  • C06 Supply Chain (hub) — broader supply-chain controls for signed artifacts, AI-BOM evidence, CI/CD enforcement, and dependency risk in AI-assisted development workflows.
  • C09-06 Shutdown & Graceful Degradation — agent containment and graceful-degradation controls that the AC.14 compromise-containment family specializes for AI-in-pipeline scenarios.