Automated API security testing: what an AI agent checks and what it cannot

Automated API security testing means software sends requests to a running API and checks the responses against security rules. An AI agent adds planning: it reads each response and picks the next request. This page lists what an agent needs, the eight checks it can run, how it proves a finding and what it misses. It stays vendor-neutral. For tool lists, see automated pentesting tools on pentestcompare.com.

What can be automated in API security testing?#

Checks that compare responses across identities, replay requests with changed values or probe limits can be automated well. Checks that depend on what your business means by "allowed" cannot, unless you write the rule down first.

For the human-led service, see API penetration testing on penetrationtestservices.com. This guide covers the automated side.

What does an agent need before it starts?#

An agent needs four inputs: a spec or route list, a base URL, test accounts and a written scope. Without accounts it cannot test authorization.

1. The OpenAPI (or similar) spec, or a captured route list. The agent also reads client-side JavaScript for routes the spec leaves out.
2. A staging base URL, for example https://api.staging.example.com.
3. Two test accounts per role, plus one admin account if admin routes are in scope. Mark them as test data.
4. A written scope that names hosts, accounts, allowed actions and rate limits, with the owner's written authorization.

Our AI testing agents also run under tool rules. Each tool the agents can use runs on its own, waits for approval or is blocked, and Excession Labs sets those rules for each scope.

Which eight checks map to the OWASP API Top 10 2023?#

The OWASP API Security Top 10 2023 names ten risks. Eight of them have a check an agent can run with an account pair and a spec. API6 (Unrestricted Access to Sensitive Business Flows) and API10 (Unsafe Consumption of APIs) depend on business context and on how your API calls others, so a person leads those.

OWASP describes API1 as attackers changing "the ID of an object that is sent within the request". Our guide on how AI agents test authorization covers checks 1 and 5 in detail. The OWASP API Top 10 guide on penetrationtestservices.com explains each risk and its fixes.

How does an agent prove an API finding?#

An agent proves a finding by showing an effect, then reading it back from a second account. A 200 response is not proof. The same rule applies to every row in the table above.

GET /api/v1/notes/101 HTTP/1.1
Host: api.harbor-notes.example.com
Authorization: Bearer <token for test user B>

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 101, "owner": "test-user-a", "title": "Test note A"}

For a longer worked case with a rejected false positive and a retest, read the example assessment. It uses a fictional e-commerce API.

A write needs the same care. If the agent changes a record as one account, it must read the record back through another session. A bare "success" message may mean the server accepted the request and ignored it.

What does automation miss in APIs?#

Automation misses flaws that need your intent. Four gaps recur.

1. Business flows. A coupon that must work once, or a refund path that skips approval, looks valid to an agent without the rule.
2. Shared records. Whether two users should see the same object is a product decision.
3. Chains. Joining a small information leak with a weak function check into serious impact still takes human judgment.
4. Severity. Someone on your side must decide what risk to accept.

This is why Excession Labs checks the evidence for each finding and writes the report. AI pentesting false positives shows what happens when no one checks.

What are the safe limits for automated API tests?#

Safe limits are written into the scope before the first request. Automated tests create and change data and can cost money, so bound each part.

Reproduction scripts should be read-only where possible. Run them only with authorization and test-owned identifiers.

Where does it fit in releases and CI?#

Run fast, bounded checks on each build and agent-led testing on larger changes. A schema check, a two-account read test on a few routes and a spec-versus-live diff are cheap enough for a pipeline. Full flow testing costs more per run. Pentesting in CI/CD shows where each step fits, and per-release testing describes testing after a major change.

If you also run a DAST scanner, compare the two on one build with the method in AI pentest agents vs DAST scanners. To see an agent-led test on a small written scope, apply for the free pilot.