Three security tools, three reports, one decision
SAST, DAST and SCA each see one layer. An agent in GitLab CI reads all three per build and returns one report: what blocks the release, and why.
Most pipelines that take security seriously run at least three tools. SonarQube reads the source code (SAST). OWASP ZAP attacks the running application from outside (DAST). An SBOM, generated at every build in CycloneDX format and loaded into Dependency-Track, lists every component and the known vulnerabilities attached to it (SCA). Each tool is good at its layer. None of them knows what the other two found.
The result is familiar to anyone who has maintained such a pipeline: three dashboards, three severity scales, a long list of findings that nobody reads in full, and a release decision taken on whichever report someone happened to open. A critical vulnerability in a library is treated the same whether the vulnerable function is reachable from the internet or never called. A warning from ZAP on a header and a hotspot in SonarQube on the same endpoint are triaged separately, by different people, on different days.
One agent after the three scans
While I was CTO of a B2B software house, I built a GitLab CI stage that puts one agent after the three scans. It reads the SonarQube findings, the ZAP report and the components and vulnerabilities held in Dependency-Track for the same build, and writes one report per build: an overall risk index, then the considerations that combine the three points of view. Which findings refer to the same weakness seen from different sides, which ones are exposed in the running application, which ones can wait, whether the release should be blocked. Every conclusion carries the findings it is based on, so a person can check it quickly instead of reconstructing it.
The model is Claude Haiku, a small and fast model. That is a deliberate choice: the hard part is not reasoning power but giving the model the right findings, side by side, and constraining what it may conclude. A larger model reading badly prepared input would not do better.
Three rules that matter more than the model
The agent does not decide alone what blocks a release. The blocking thresholds are written in the repository, with the reason next to each one; the agent applies them and explains its reading, and a person can override with a written motivation.
The agent never sees more than it needs. Findings, component lists and endpoints, not secrets, credentials or customer data.
The pipeline must prove it can fail. Before trusting the assessment, a known vulnerable component and a known weak endpoint are introduced on purpose and the build must turn red. A security check that has never been seen failing is not a check.
Limits
The agent reduces the reading work, not the responsibility: a false negative in any of the three tools stays a false negative after the agent. Reachability is assessed from what the tools report, not proven by exploitation. No figures on triage time or false positives are given here: the build data stayed with the company where the stage was built, and I do not quote numbers I cannot show.