Skip to content
Best Agentic AppSec logoBest Agentic AppSec

LESSON 8 OF 10 · RUNNING IT · 3 min read

Measuring an agentic AppSec program: the metrics you can collect

Short answer

Measure an agentic AppSec program with a few metrics you can collect from your own systems: how much of the agent estate you can see, what gets blocked, how often fix agents' changes are accepted, how long findings take to fix and how often they come back. Avoid vendor-supplied benchmarks as your success measure; use your own baseline.

By The Pipeline Desk · Best Agentic AppSec · Published 2026-10-07 · Updated 2026-10-11

Why your own baseline matters

Vendor figures come from vendor workloads. The only numbers that tell you whether your program works are your own, measured before and after a change. Take a baseline for each metric below before you turn on a new control or agent.

Governance metrics

  • Agent inventory coverage. The share of developer machines or repositories where you know which agents, models and MCP servers are in use. Rising coverage is the first sign the discover phase is working.
  • Unapproved MCP servers in use. A count over time, from your inventory.
  • Blocked actions per week. Split by rule. A rule that fires constantly is either catching a real problem or needs rewriting.
  • Exceptions granted and their age. Exceptions without an expiry turn into permanent holes.

Remediation metrics

  • Fix acceptance rate. The share of agent-written fix pull requests that a reviewer merges without rewriting. It is the clearest single measure of a fix agent's usefulness.
  • Validated before review. The share of agent fixes that passed a re-scan or tests before a person saw them. Legit Security says its remediation agents re-scan before and after a fix; GitHub says agentic autofix validates its own Code Quality fixes. Check that the validation actually runs in your setup.
  • Time to fix. From finding to merged fix, by severity. Compare agent-fixed and human-fixed findings separately.
  • Reopened findings. Findings that come back after a fix was merged.

Triage metrics

  • Share of findings auto-deprioritized. And how many of those a spot check would have kept.
  • Critical findings older than your policy allows. The metric executives understand.

Tie metrics to a framework

NIST's Secure Software Development Framework groups practices into Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities. Mapping each metric to one group makes it easier to report on the program to auditors and customers who ask about the SSDF.

Keep the set small

Pick four or five metrics, collect them monthly, and show the trend. A dashboard of thirty numbers hides the two that matter.

Where the data comes from

Most of these numbers come from systems you already run: source control for pull requests and merges, the AppSec platform for findings and their status, and the agent governance tool for inventory, blocks and exceptions. Agree on definitions before the first report. "Fixed" should mean merged and verified by a re-scan, not only a closed ticket, and "agent-written" should be tagged on the pull request so it can be counted.