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
One lock on the door is good; two locks is better — especially when one is checked by the agent and the other is checked by a separate CI gate. In-loop scanning lets you fix issues before they become pull request noise, while GitHub Actions scanning provides independent verification that the agent didn't rationalize its own findings. Defense in depth wins.
Full Explanation
The correct approach 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 pull request. If SAST finds issues, the agent can attempt to remediate them autonomously in the same session. This reduces the number of vulnerable pull requests that are ever opened, keeping the pull request 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): this runs independently of the agent, triggered by pull request creation. It provides an objective, agent-independent verification that the code meets security standards. It acts as a safety net for cases where the agent's internal scan missed something, the agent rationalized away a finding, or the inner-loop scan configuration differs from the CI configuration. It blocks merge if findings exceed threshold, regardless of what the agent reported.
The GitHub Actions-only approach is wrong because it leaves the agent operating in a scan-blind mode during code generation, opening potentially vulnerable pull requests that then require CI cycles to detect and fix, which is inefficient and noisy. The agent-internal-only approach is wrong because it 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. The approach that relies only on the code review agent's LLM-based security analysis is wrong because LLM-based analysis is probabilistic and cannot match the determinism and completeness of a purpose-built SAST tool operating on parsed abstract syntax trees and known vulnerability signatures.