Agentic API security testing
Operator tests every operation in your OpenAPI spec the way an attacker would, across users and tenants, and proves each finding with the exact request and response.
Findings are cheap. Proof is the product.
A scanner hands you a list of maybes. The agent hands you a finding it already reproduced, with the exact requests, responses, and steps that make it true. If it cannot prove a thing, that thing never reaches your report.
Every result carries a CVSS v3.1 vector you can verify yourself, the components it touches, and remediation aimed at the layer that must change. When you want a person's signature on it, a senior practitioner validates it before it lands. Every finding ships with a runnable proof-of-concept your engineers can execute themselves, not a screenshot to take on faith.
- discovered a public JavaScript bundle
- extracted a broker token committed into the bundle
- replayed the token against the admin API and authenticated
- reached 14,213 order records across tenant boundaries
Example finding. Target details redacted.
What is Operator?
Operator is an autonomous, agentic API penetration testing agent. From your OpenAPI spec it tests every documented operation you include, reasons across operations to find the object- and function-level authorization flaws (BOLA and BFLA) that pattern-matching scanners miss, and reports only findings it has already reproduced, each rated with a CVSS v3.1 vector and, on request, validated by a senior offensive security team.
Tests your API’s authorization, and other weaknesses
It attacks each operation across different user and tenant identities, hunting broken object- and function-level authorization (BOLA, BFLA), broken authentication, and injection.
An API URL, an OpenAPI spec, and test identities
Point it at your API base URL, upload or link your OpenAPI/Swagger spec, and add one bearer token per role so it can test across accounts. You choose which documented operations are in scope.
Proof you can act on in minutes
Each finding ships with the exact request and response, step-by-step reproduction, a CVSS v3.1 vector, and remediation guidance aimed at the layer that must change.
- Category
- Agentic API penetration testing · autonomous API security testing
- Also known as
- Autonomous API pentesting, continuous API testing, spec-driven API security
- Coverage
- REST, GraphQL, and gRPC APIs, plus the agents and RAG systems behind them
- Method
- OWASP API Security Top 10, ASVS, PTES, NIST SP 800-115, CVSS v3.1
- Delivery
- Managed capability · fixed scope and price · findings routed to your existing tools
- Provider
- Planck Proof
One agent, the full attack sequence
You give it your API base URL and OpenAPI spec. It parses the spec, tests every operation the way an attacker would, and proves what it finds, without a human driving each step. You set the scope and read the results.
Scope and parse the spec
You provide a verified domain, the API base URL, your OpenAPI or Swagger spec, and one bearer token per user role. It lists every documented operation, method, and parameter in scope. Scope is a hard boundary enforced in software, and only documented operations are tested, no blind fuzzing.
Reason and cross-test
For every operation it reasons about what an attacker would try, and replays one role’s requests as another to reach the authorization flaws (BOLA and BFLA) that scanners cannot.
Verify and report
It tests, chains what it finds, reproduces each result to strip out noise, rates it with CVSS v3.1, and delivers it with the evidence attached. Anything it cannot prove does not reach your report.
What the agent does on its own
Each stage feeds the next, so the testing at the end is aimed by everything the discovery at the start turned up. No inventory to hand over, no scan to configure, no result to hand-triage before it means something.
Every operation, parsed
From your OpenAPI or Swagger spec it builds the full list of operations, methods, parameters, and request bodies in scope, so nothing documented goes untested.
Cross-account BOLA & BFLA
With one token per user type, it replays one role’s requests as another to surface the object and function level authorization flaws that dominate real API breaches.
Token and session testing
It probes for forgeable or non-expiring tokens, weak JWT handling, and unauthenticated endpoints that should require a session, the failures that undo every other control.
Injection and mass assignment
It tests every parameter the spec exposes for injection, and probes for mass assignment and object-property abuse: setting fields you should not, reading fields that should never leave the server.
Autonomous testing and chaining
It plans and runs test cases against each operation, then chains what it finds. A leaked token becomes an authenticated call; a permissive endpoint becomes access; a single low finding becomes a real path in.
Continuous re-testing
Your API changes with every deployment. The agent re-runs on every change, so a new endpoint shipped on a Tuesday is tested that week, not at next year’s assessment. Coverage tracks your spec, not the calendar.
Full attack coverage, mapped to the OWASP API Security Top 10
- Broken Object Level Authorization (BOLA): requesting other users’ objects by ID across accounts and tenants. For example, signed in as one customer, calling
GET /orders/1043and receiving another customer’s order. - Broken Function Level Authorization (BFLA): calling admin and privileged functions from a lower-privileged role. For example, a standard user calling
DELETE /users/12orPOST /admin/refundsand having it succeed. - Broken authentication: forgeable or non-expiring tokens, weak JWT handling, and unauthenticated endpoints
- Object property level authorization & mass assignment: setting fields you should not, reading fields that should never leave the server
- Injection: SQL, NoSQL, command, and query injection on every parameter the spec exposes
- Unrestricted resource consumption: missing rate limits and unbounded queries that exhaust or bill your infrastructure
- SSRF, misconfiguration & inventory: server-side request forgery, security misconfiguration, and shadow or deprecated endpoints
- Attack chaining: individually low findings combined into the path an intruder would actually walk
Not a scanner, not a once a year snapshot
The agent sits where scanners, annual manual tests, and one-shot AI tools each fall short: continuous coverage, proven exploitability, and a human you can put behind any finding.
| Operator | Vulnerability scanner | Annual manual pentest | Single-shot AI tool | |
|---|---|---|---|---|
| Cadence | Continuous, on every change | Continuous but shallow | Once a year | A single run |
| What you receive | Exploit-proven findings | Unverified alerts | Verified snapshot | Often unverified output |
| False positives | Reproduced before delivery | Common, triaged by you | Low, by hand | Varies by tool |
| Human validation | On demand, same team | Not included | Inherent | Rarely |
Where teams point the agent first
One capability, several jobs. Most teams start with the surface that changes fastest or worries them most. See all use cases and API penetration testing by industry for how this plays out in your sector.
Isolation that has to hold
Cross-tenant access, object-level authorization, and shared infrastructure tested the way one customer would try to reach another.
An API release before it ships
Point the agent at your API in staging and get an exploit-level read before your users, or an attacker, do. Then re-test every operation on your release cadence.
The APIs behind your AI
Tool and function-call abuse, and the APIs your agents can reach, tested the way an attacker would drive them.
Findings land where your team already works
The run is autonomous. The output arrives in the tools your engineers live in, so a proven finding becomes a pull request comment, a ticket, or an alert without anyone passing a PDF around. Every message carries the same evidence as the report: the request, the response, and the steps to reproduce. See integrations.
- finding BOLA on
GET /api/v3/orders/{id}: account A read account B’s order - proof request and response attached · reproduced 2 of 2 · CVSS 9.1
- fix enforce ownership at the data layer, not only at the route
- tracked Jira SEC-142 opened · #security notified in Slack
Illustrative output. Ticket and channel names are examples.
Autonomous, and under your control
Running an attacker against your live systems is only acceptable if the controls are real. Ours are enforced in software, not promised in a slide, and the standard behind the output does not move: a finding either reproduces or it never appears in your report, and a severity either follows CVSS v3.1 or it does not get printed.
Behind the agent is a senior offensive security team. They can validate any finding before it reaches you, and go deep on the hard targets where a person still outreasons automation. When you want a human engagement, it is the same people, on the same standard.
- Scope is a wall. Testing stays inside the assets and windows you define, enforced in the system rather than left to a tester's judgment in the moment.
- Non-destructive by default. The agent runs read-mostly, honors rate limits, and paces its traffic. Anything with real side effects is blocked unless you authorize it in writing.
- Approval gate and kill switch. Sensitive actions wait for your explicit approval, and you can stop any run instantly. You are never watching a black box you cannot halt.
- Human validation on demand. Route any finding, or an entire run, through a senior practitioner before it reaches your tracker.
The questions security teams ask first
What is agentic penetration testing?
Agentic penetration testing uses an autonomous AI agent that reasons its way through an attack the way a human tester would: it maps the operations your API exposes, decides what to test, chains findings into real exploit paths, and reproduces each result before reporting it. Unlike a vulnerability scanner, which runs fixed signatures and hands you unverified alerts, an agentic pentester adapts to what it finds and proves exploitability, as covered in agentic pentesting vs DAST. Operator is an agentic penetration testing agent that runs this sequence continuously and rates every finding with CVSS v3.1.
How is Operator different from a vulnerability scanner?
A vulnerability scanner matches signatures and returns a queue of unverified alerts you have to triage. Operator reproduces every finding before it reaches you, chains individually low findings into the real path an intruder would walk, re-maps the full surface on every change instead of relying on a static signature set, and lets you route any finding through a senior practitioner for a human signature. You receive proof, not a list of maybes.
Can it run against production safely?
Yes. The agent defaults to non-destructive testing, honors rate limits, and enforces scope in software rather than in a tester's memory. Anything with real side effects waits for your written approval, you can restrict it to staging, and you can stop any run instantly with the kill switch.
Does it replace penetration testing?
It replaces the annual snapshot, not the people. The agent gives you continuous breadth and proven exploitability day to day. Our consultants still go deep on business logic, chained abuse, and the creative work automation cannot yet reason through. Both use the same report format and severity scale.
How is it delivered and priced?
Operator is delivered as a managed capability, not a tool we hand you. Operator is priced per protected API by endpoint volume, on a decreasing per-endpoint curve. Pro includes four runs a month; more runs raise the price. Development, staging, and production cost the same. Your First Scan is free. Final scope and price are quoted.
Point the agent at your API
Give us a domain and the rules of engagement. We will return a scoped run and show you what it surfaces, including the assets you did not know were yours.