Understanding Pentest Coverage

Coverage is the percentage of discovered endpoints that Aikido actively tested during a pentest run.

During discovery, Aikido maps the endpoints, features, and API routes it can find. During exploitation, autonomous agents test the most relevant targets for real vulnerabilities.

Coverage is the ratio of covered endpoints divided by the amount of discovered endpoints.

This uses the endpoints Aikido discovered during the run. That includes white-box testing, and grey-box testing when you provide an API specification.

What counts as "covered"?

An endpoint is covered when one or more agents run meaningful security checks against it.

Those checks can include:

• Injection testing

• Authentication bypass attempts

• Authorization bypass attempts

• Business logic abuse

• Other endpoint-specific exploit paths

The exact checks depend on the endpoint's behavior and risk profile. You can inspect those assumptions in the Attack Plan of the Threat Model.

Coverage is not a quality score

Coverage does not measure pentest quality.

Human pentesters do not test every route either. They prioritize endpoints most likely to contain exploitable issues. Aikido does the same.

A password reset flow matters more than a static asset route. An admin action matters more than a health check endpoint.

Low-value endpoints can remain uncovered without reducing the value of the pentest.

Why is coverage not 100%?

Each pentest has a fixed credit budget. That budget translates into agent compute time.

Agents spend that time on the highest-value targets first. If the budget runs out before every endpoint is tested, the remaining endpoints are usually the lowest-priority ones.

Other common reasons:

• Large applications have more endpoints to explore and test.

• Some endpoints require specific state, chained actions, or rare preconditions.

• Some flows are only reachable after complex user journeys.

• Server state during the run can change what agents can access.

Request count variation

Some endpoints show thousands of requests. Others show only a few. That is normal.

A complex endpoint needs many payloads to test injection types, boundary conditions, and edge cases. A simple read-only endpoint may only need a few requests.

High request counts usually mean deep testing. Low request counts usually mean the endpoint had limited attack surface.

Differences in coverage between tests

Two runs on the same application can still produce different coverage.

Aikido's agents make decisions dynamically. They may:

• Take different exploration paths

• Discover endpoints in a different order

• Spend more time on an area that looks promising

• React to application state that changed since the last run

That variation is useful. Different runs can uncover issues that a single deterministic scan would miss.

Compliance and coverage

A coverage score below 100% does not mean you are non-compliant.

Frameworks like SOC 2, ISO 27001, and NIS2 require penetration testing of your application. They do not require 100% endpoint coverage.

No common standard sets a minimum coverage percentage. That is because real pentesting is risk-based, not route-count-based.

Auditors care more about:

• A repeatable testing process

• Documented findings

• Evidence of remediation

• Regular reassessment

An Aikido pentest supports that workflow.

Coverage and findings

There is no direct link between coverage and number of findings.

Examples:

• A well-secured app can have high coverage and zero findings.

• A smaller app can have lower coverage and still contain critical findings.

The goal is to find real, exploitable vulnerabilities. The goal is not to maximize a coverage number.

Can I get more coverage?

Soon, you will be able to launch additional agents against uncovered endpoints listed in the Coverage tab.