Securing AI coding agents in the SDLC — the CISO playbook

Use this playbook when an AI coding agent holds standing access to your source tree or build pipeline: a pull-request bot, an issue-triage agent, a Copilot-, Claude-Code- or Codex-class assistant wired into CI, or any autonomous workflow that can read a repository, run shell commands, and push commits. The defining risk is that the agent reads attacker-influenceable text — an issue title, a PR comment, a committed config file — while holding credentials meant for trusted automation.

In scope: the agent's identity and repo/CI permissions, how untrusted repository inputs reach its context, the human review gate for AI-authored code, and the provenance you keep to prove what the agent did.

Out of scope: the general cross-agent control set (agent identity, MCP governance, egress monitoring for any kind of agent) — that is the agentic AI security controls playbook; and defending against a poisoned third-party dependency the agent happens to pull, which is the signed-malware supply-chain response playbook. This playbook is the SDLC-specific case where the agent's blast radius is the source tree and the build.

Classic application security assumes code paths are fixed and inputs are data. A coding agent breaks both: it decides at runtime which tool to call, and it treats repository content — issues, PR comments, file contents, even a committed .env — as instructions. A run of 2026 disclosures showed the cost, and they share one root cause: an agent processed untrusted text while holding credentials meant for trusted automation.

• The agent's own safety setting is not a security boundary. In CVE-2025-66032 (CVSS 8.7), shell-parsing flaws around $IFS and short CLI flags let untrusted content in the Claude Code context bypass the agent's read-only validation and run arbitrary code; fixed in @anthropic-ai/claude-code 1.0.93.
• CI config is executable the moment an agent reads it. CVE-2026-12537 (CVSS 10.0) let a crafted .gemini/.env run commands on the CI host because headless Gemini CLI auto-trusted the workspace folder — and separately ignored its own tool allowlist under --yolo; fixed in @google/gemini-cli 0.39.1 and the run-gemini-cli action 0.1.22. A workflow that merely reviews a submitted pull request would execute the attacker's commands.
• A pre-approved destination is an exfiltration channel. CVE-2026-54316 (CWE-183) pre-approved the bare host huggingface.co for Claude Code's WebFetch, so an agent coerced by injected content could stream files and environment variables out through an attacker-controlled model repository; fixed in @anthropic-ai/claude-code 2.1.163.

Researchers at Black Hat USA in August 2026 generalized the pattern as Comment and Control: a single PR title, issue comment, or HTML comment could make a coding agent leak GITHUB_TOKEN and provider API keys into publicly readable Actions logs, with no maintainer action beyond the automated trigger. None of these were model failures in isolation — they were inherited secrets, overbroad tokens, unsafe config loading, and permissive egress. The controls below bound exactly those.

Goal: the agent is a named principal whose repository and pipeline permissions match the task, with no standing write access or broad secrets between runs.

• Give each agent its own identity — a dedicated machine account or app installation, never a human maintainer's token or a shared service account. You need per-agent attribution when you reconstruct an incident.
• Scope repository access to what the task needs. An issue-triage agent needs read and comment, not contents: write. Grant write only to the specific repos and, where the platform allows, specific paths.
• Scope CI permissions per workflow. Restrict id-token: write and contents: write to the jobs that genuinely need them; a triage or review job should have neither.
• Keep secrets out of reach of untrusted triggers. Do not expose provider API keys or a write-scoped GITHUB_TOKEN to workflows that run on issue_comment or pull_request_target from forks.
• Pin third-party actions, including the agent's own action, to a full commit SHA rather than a floating tag, so an upstream compromise does not silently roll into your pipeline.

Checklist:

• [ ] Each agent has a distinct, inventoried identity; no shared or human accounts.
• [ ] Repo write scoped to specific repos/paths; read-only where that suffices.
• [ ] id-token: write and contents: write restricted to jobs that need them.
• [ ] No secrets exposed to fork-triggered or comment-triggered workflows.
• [ ] Third-party actions pinned to commit SHAs.

Goal: nothing the agent reads from a repository — issue, PR, comment, file, or config — is trusted as instruction by default.

• Sanitize or clearly delimit untrusted metadata before it reaches the agent's context. Treat issue and PR titles, bodies, comments, and HTML comments as hostile input, the same way you treat user input to any other system (OWASP LLM01 Prompt Injection).
• Never let repository config files execute implicitly. Require explicit opt-in to trust a workspace — the fix pattern behind CVE-2026-12537 — and do not let .env, agent instruction files (AGENTS.md, .gemini/), or settings in the checked-out tree widen the agent's permissions.
• Keep the tool allowlist authoritative. An auto-approve or --yolo mode that ignores the fine-grained allowlist turns one prompt injection into shell execution — the allowlist must hold regardless of mode.
• Constrain outbound network access from CI runners to a known-good destination list. A single over-broad pre-approved host (CVE-2026-54316) is enough to exfiltrate; default-deny egress is the backstop when a policy gate is only advisory.
• Require recorded human approval for high-consequence tool calls — push to protected branches, publish, deploy, pay — rather than leaving them to model discretion. This is the SDLC instance of bounding excessive agency, LLM06.

Checklist:

• [ ] Untrusted repo text is delimited/sanitized before entering agent context.
• [ ] Workspace and config trust is explicit opt-in, never implicit.
• [ ] Tool allowlist is enforced in every mode, including auto-approve.
• [ ] CI egress is default-deny to a known destination list.
• [ ] High-consequence actions require recorded human approval.

Goal: AI-written code reaches a protected branch only through a review gate a human actually exercises, with provenance recorded.

• Make the review gate mandatory and enforced by branch protection, not advisory. An agent must not be able to approve its own pull request or merge without a human reviewer, and local --no-verify-style bypasses must be irrelevant because the gate lives at the remote.
• Right-size review capacity to the volume. Agents raise PR throughput; if reviewers cannot keep up, the gate degrades into rubber-stamping and becomes theater. Cap concurrent agent PRs to what your reviewers can genuinely read.
• Keep deterministic pre-merge checks that do not depend on the agent behaving: secret scanning, SAST, dependency and license checks, and build/test must pass on the agent's branch as on any other.
• Record provenance for AI-authored changes — which agent, which model and version, which prompt or task, and the human approver — so you can answer who and what wrote this after the fact. Build-level provenance (SLSA) ties the artifact back to the pipeline that produced it.
• Treat the agent-action log as a control, not a nicety. A missing log makes an incident uninvestigable.

Checklist:

• [ ] Human review enforced by branch protection; agents cannot self-approve.
• [ ] Concurrent agent PR volume capped to reviewer capacity.
• [ ] Secret scan, SAST, dependency check, and tests gate every agent branch.
• [ ] Provenance recorded per AI-authored change (agent, model, task, approver).
• [ ] Agent actions are logged and retained for investigation.

Have these ready — signed, timestamped, with chain-of-custody — for an audit or an incident involving a coding agent:

• Inventory of every coding agent: owner, identity, repos and paths it can write, secrets it can read, CI permissions, egress destinations.
• Branch-protection and required-check configuration for every repo an agent touches.
• The agent-action log (prompts/tasks, tool calls, commits, approvals) for the window under review.
• Provenance records for AI-authored merges (agent, model and version, approver).
• The pinned-SHA list for third-party actions and the date of the last CI permission review.

The hard question an auditor or a board asks after an agent incident is not did you review the diff — it is can you prove the code paths the agent touched are actually safe. A review reads intent; it does not demonstrate exploitability. This is where the Zero Hunt autonomous AI red team fits: it exercises the application the agent is writing — the authenticated flows, the input-reachable paths — and where a weakness is real it generates a working proof-of-concept against the exact installed version, black-box by default and gray-box when you hand it the source, rather than returning a flat list of maybe-issues. Every finding is signed at write time (Ed25519, hash-chained), so the evidence that an AI-written path was tested is itself verifiable. Because the engine runs on-premise on its own models with a human in the loop for anything that matters, the code and secrets it reasons over never leave your estate — which is the point when the thing under test is your source tree.

1. The agent runs as a human maintainer. It inherits that person's full repo and org access, and every action is attributed to them — you lose least privilege and forensics in one step. Give the agent its own scoped identity.

2. Trusting the agent's read-only or sandbox label as a boundary. CVE-2025-66032 and CVE-2026-12537 both defeated exactly that assumption. The security boundary is the identity, the token scope, and the egress policy — not a mode flag the model enforces on itself.

3. Secrets exposed to fork or comment triggers. Workflows on pull_request_target or issue_comment that can read provider keys or a write-scoped GITHUB_TOKEN are the Comment and Control class: one external comment leaks them into logs. Partition untrusted-trigger workflows from secret-bearing ones.

4. The review gate as theater. When agent PR volume outruns reviewer capacity, approvals become reflexive and the gate stops catching anything. Cap the volume or add reviewers; a rubber-stamped gate is worse than an honest manual process because it looks like control.

5. No provenance, no audit log. After an incident you cannot say which agent wrote the change, under which model, or who approved it. Record it at merge time — reconstructing it from Git history alone is usually impossible.

6. Over-broad egress allowlists. A single bare-hostname pre-approval (CVE-2026-54316) is an exfiltration channel. Scope egress to specific endpoints and default-deny the rest.

A coding-agent program answers to several regimes at once, and one control set covers them:

• NIS2 Art. 21 lists security in development and acquisition among the baseline measures; an ungoverned agent with repo access is a gap an ACN/ENISA assessment will probe.
• DORA Art. 24-25 (finance) expects regular, evidence-producing testing of the ICT that supports critical functions — including the pipeline that ships it.
• CRA Art. 13 obliges product manufacturers to run secure development and a vulnerability-handling process; AI-authored code in a product with digital elements is in scope.
• EU AI Act: if the coding agent is itself a high-risk or general-purpose AI system, its own governance obligations phase in — plan for them rather than discovering them in an assessment.
• NIST SSDF (SP 800-218) and its generative-AI companion SP 800-218A give the practice vocabulary — protect the pipeline, review the code, archive provenance — that maps onto the three control domains above; the OWASP Agentic Security Initiative supplies the threat catalog.

Build the evidence once and export per regime. Continuous, exploitability-ranked validation of the code your agents ship — rather than an annual pentest already stale by merge day — is the offensive-testing sibling to this governance set; see continuous automated penetration testing and, for how it slots into exposure management, CTEM.