Automated scanning flags a vulnerability in agent-written code. What should happen?
Why C is the answer
Treat the result as a signal to fix the code and tune the agent
Scanning results are evaluation signals. Findings should feed both the fix and the tuning of the agent.
In detail
- A finding is a signal to fix the code.
- It also shows how to tune the agent.
- Keep the scan on, because it found the problem.
Use case
An illustrative scenario, not a real incident.
A scan flags a SQL injection in agent code. The team fixes it and adds guidance, so the same mistake is less likely next time.
See it in different ways
flowchart LR A["Agent output"] --> B["Tests and code scanning"] A --> C["Reviewer feedback"] B --> D["Evaluation"] C --> D D --> E["Tune the agent"]
sequenceDiagram participant T as Team participant A as Agent participant R as Results T->>T: Set success criteria A->>R: Several runs, across tasks R-->>T: Tests, scans and review signals T->>A: Keep or drop the change
flowchart LR S0["Scan flags an issue"] --> S1["Fix the code"] --> S2["Tune the agent"] --> S3["Scan again"]
Key point: A finding is a signal to fix and tune.
Why the other options are wrong
- A. Delete the scanning results, so that the pull request looks cleaner
- Deleting results hides the risk.
- B. Disable the rule that fired, so that future runs finish quickly
- Disabling a rule removes the protection.
- D. Merge it, because agents do not usually introduce security problems
- Agents can introduce security problems.