A security team wants to ensure that code generated by their autonomous coding agent meets organizational security standards before being merged. They propose running SAST (Static Application Security Testing) scans on agent-generated pull requests. A developer suggests adding the SAST scan as a GitHub Actions workflow triggered by the PR creation event. An architect suggests making the SAST scan a blocking evaluation gate in the agent's own execution loop. Which approach BEST integrates security scanning into the agentic evaluation pipeline?
Select an answer to reveal the explanation.
Short Explanation and Infographic
One lock on the door is good; two locks is better — especially when one is picked by the burglar (the agent) and the other is picked by a separate locksmith (GitHub Actions). In-loop scanning lets the agent fix issues before they become PR noise; CI scanning provides independent verification that the agent didn't just rationalize its own findings. Defense in depth wins.
Full explanation below image
Full Explanation
The correct answer implements a defense-in-depth evaluation strategy with two complementary SAST integration points that serve different purposes:
Agent-internal SAST (inner loop): - The agent runs SAST as a step in its execution loop after generating code but before creating a PR - If SAST finds issues, the agent can attempt to remediate them autonomously in the same session - This reduces the number of vulnerable PRs that are ever opened, keeping the PR queue cleaner - The agent's remediation is guided by the SAST findings, not by its general vulnerability knowledge
GitHub Actions SAST (outer loop / CI gate): - Runs independently of the agent, triggered by PR creation - Provides an objective, agent-independent verification that the code meets security standards - Acts as a safety net for cases where: (a) the agent's internal scan missed something, (b) the agent rationalized away a finding, or (c) the inner-loop scan configuration differs from the CI configuration - Blocks merge if findings exceed threshold, regardless of what the agent reported
Option A (CI only) leaves the agent operating in a scan-blind mode during code generation, opening potentially vulnerable PRs that then require CI cycles to detect and fix — inefficient and noisy. Option C (agent-internal only) removes the independent verification layer. An agent that both generates code and evaluates its own output can exhibit motivated reasoning, dismissing findings that are inconvenient. The independent CI gate prevents this. Option D (LLM analysis only) is incorrect because LLM-based analysis is probabilistic and cannot match the determinism and completeness of a purpose-built SAST tool operating on parsed ASTs and known vulnerability signatures.