After deploying an agent to generate authentication code, the security team's automated scan finds SQL injection vulnerabilities, hardcoded credentials, and unsafe deserialization patterns in the agent's output. The agent reported task completion after all unit tests passed. Which step was missing from the agent's task completion criteria?
Select an answer to reveal the explanation.
Short Explanation and Infographic
An agent that declares 'done' the moment tests go green is like a chef who plates food without tasting it — technically prepared, possibly poisonous. Security scans (SAST, secret detection, dependency checks) are not optional for code that handles authentication; they belong inside the agent's definition of done, not as a separate post-hoc discovery.
Full explanation below image
Full Explanation
An agent's definition of 'done' must encompass all quality gates appropriate for the type of code it produces. For authentication code, this must include security verification: static application security testing (SAST) to detect common vulnerability patterns (SQL injection, XSS, insecure deserialization), secret detection to prevent hardcoded credentials from being committed, and dependency vulnerability scanning to catch known CVEs in imported libraries.
These scans should be invoked by the agent as tool calls before it declares task completion — not as external CI steps that run after the agent is already done. When security issues are found, the agent should attempt to fix them or surface them as blocking issues rather than reporting success.
Option A (human review) is a valuable safety net but is not a substitute for automated security scanning in the agent's workflow. Human reviewers can miss subtle injection patterns or inadvertently hardcoded credentials, especially in large code outputs. Automated scanning catches these consistently.
Option C (unit test comprehensiveness) is a common misconception. Unit tests verify functional behavior, not security properties. A function that correctly authenticates a valid user but is vulnerable to SQL injection will pass its unit tests while failing a security scan. Security and functionality are orthogonal dimensions.
Option D (security-focused model) is a model selection consideration that might improve baseline security awareness, but does not guarantee secure output. Even security-focused models can produce vulnerable code; scanning is the verification step that confirms safety regardless of model choice.
Security scanning must be part of the agent's task completion definition, not a post-hoc discovery by external teams.