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
If your agent calls work done just because unit tests pass, it skipped the security gate. For authentication code, SAST, secret detection, and dependency checks need to be part of 'done' before it reports success.
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 such as SQL injection, XSS, and 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.
The option saying the agent should have asked a human to review the code before marking the task complete 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.
The option saying the agent's unit tests were not comprehensive enough to catch security vulnerabilities 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.
The option saying the agent should have used a security-focused LLM model rather than a general-purpose 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.