OWASP APTS: A Complete Guide to Autonomous Penetration Testing Standard

Autonomous pentesting platforms are sitting at the top of HackerOne’s US leaderboard, surfacing zero-days in systems that had passed traditional audits for years. The capability is real, it is here, and it is only getting faster.

But CISOs and procurement teams are not rushing to deploy it. The same period that produced those leaderboard results also produced a string of agentic AI incidents: production databases deleted, systems taken offline, all by agents that had valid permissions and still caused damage no one authorized.

Moreover, layered on top of it is a quieter concern in the security community: that autonomous pentesting is being pushed more by the AI wave than by genuine claims from vendors. 

If you’re skeptical about autonomous penetration testing, OWASP APTS is the answer. The Autonomous Penetration Testing Standard (APTS) is OWASP’s governance framework for the space. In this blog, we explain what APTS is, how it’s structured, and how it helps both buyers and builders succeed with confidence.

What is APTS?

APTS is a governance standard for autonomous penetration testing platforms. It defines what these systems must do to operate safely, transparently, and within defined boundaries, whether delivered by a vendor, run as a service, or built in-house by an enterprise security team.

APTS is not a penetration testing methodology and does not specify how an autonomous platform should perform a pentest. It complements PTES, OWASP WSTG, and OSSTMM by addressing problems those standards were never designed for, i.e., autonomy.

The standard applies to SaaS platforms, on-premises tools, integrated orchestration platforms with autonomous testing layers, and internally built enterprise tools. Manual pentesting, SAST/DAST tools, bug bounty programs, and human-led red team exercises are out of scope.

Why Businesses Need It

Traditional pentesting tools have never made a decision mid-engagement. A scanner runs what it is told to run, while the human pentester makes every call based on the context. That has always been the safety contract between the tool and the environment in which it runs.

Autonomous AI agents break that entirely.

You cannot reliably do the same thing with an agent. That decision-making capacity, compounded across dozens of actions per minute, is what makes autonomous tools categorically different from anything security teams have procured before.

Everyone in the security realm knows the horrors of AI agents in various other domains and is skeptical about it before giving it access to the crown jewel of the org, i.e., access to sensitive production environments. And that skepticism will not move until there is a verifiable, structured answer to a very simple question “How do we know this platform will not go rogue?”

That is exactly what APTS delivers. It functions as a shared governance contract between three groups who have historically been talking past each other:

• For buyers and CISOs: a domain-by-domain evaluation framework to assess whether a platform is safe to deploy, what autonomy level it can operate at, and what accountability trail it leaves behind.
• For platform builders and vendors: a concrete set of requirements to make the autonomous pentesting engagements safe.
• For security reviewers and auditors: A versioned, requirement-level reference for specific, comparable, and contractually enforceable conformance claims.

How is APTS structured?

OWASP APTS launched as v0.1.0 in April 2026, the first formal governance standard the autonomous pentesting category has ever had. As discussed earlier, it addresses the failure modes that other standards were never designed for, e.g., what happens when a system picks its own targets, runs against production, etc.

The standard is built around 173 requirements distributed across eight domains:

• Scope Enforcement (SE): what the platform is allowed to touch and how that boundary is enforced at runtime, not just at configuration
• Safety Controls & Impact Management (SC): what the platform is physically capable of doing and what is structurally off-limits, enforced outside the model itself
• Human Oversight & Intervention (HO): when a human must be in the loop, what that oversight must look like, and what response time SLAs apply
• Graduated Autonomy Levels (AL): how much independent action the platform can take and under what conditions, across four defined levels
• Auditability & Reproducibility (AR): what gets logged, where those logs live, and whether findings can be independently reproduced
• Manipulation Resistance (MR): how the platform behaves when the target environment actively tries to influence or mislead it
• Third-Party & Supply Chain Trust (TP): the foundation model, third-party dependencies, and what re-assessment is triggered when any of them change
• Reporting (RP): the structure, confidence scoring, and verifiability of what the platform actually delivers

Those 173 requirements are organized into three conformance tiers that stack cumulatively.

• Tier 1 Foundation (72 requirements) sets the floor: the platform will not test outside the defined scope, can be halted immediately, and produces a basic audit trail.
• Tier 2 Verified (157 cumulative) raises the bar to tamper-proof logging, reproducible findings, and formal third-party dependency management.
• Tier 3 Comprehensive (all 173) is the standard for critical infrastructure and fully autonomous operations.

Running alongside the tiers are four autonomy levels: L1 Assisted, L2 Supervised, L3 Semi-Autonomous, and L4 Autonomous.

Each one carries distinct containment requirements and oversight obligations that the next level builds on.

The standard also ships with a Vendor Evaluation Guide, an Evidence Request Checklist, and Customer Acceptance Testing procedures in its appendices, giving buyers a ready-made framework for turning conformance claims into testable questions before any contract is signed.

Best Practices for Adopting Autonomous Pentesting with APTS

Most procurement conversations around autonomous pentesting start with capability questions like what the tool can find, how fast, etc. Those are valid questions, but they come too early.

Before any of that, you need to know whether the platform can be trusted to operate in your environment. That is where APTS changes the conversation.

Classify your assets

Use the four asset criticality categories defined in APTS-SE-005: Critical, Production, Non-Production, and Unknown. This single step determines your minimum acceptable conformance tier and your maximum appropriate autonomy level for every use case you intend to run. 

A platform that is perfectly adequate for continuous testing against a non-production staging environment may be completely unfit for an L3 engagement against a production financial system. Know which you are buying for before the first sales call.

Use APTS to structure your RFP

APTS encourages buyers to ask vendors how they enforce scope, what their safety guardrails actually do with specifics, and whether they can show a preliminary test plan before any offensive action is taken.

The Vendor Evaluation Guide in the APTS appendices translates all eight domains into procurement questions. Use those questions verbatim, and vendors who cannot answer them should be avoided.

Ask for evidence

APTS doesn’t have any certification bodies or mandated third-party audits. That means there’s a chance a vendor could make an unverified claim. Ask them to map their responses to specific APTS requirement identifiers.

The procurement team can do this by requesting evidence or documentation on audit trail samples and records of adversarial validation per APTS-MR-020. A conformance claim with no evidence trail is indistinguishable from marketing claims.

Bring APTS into your acceptance testing.

APTS standard has a proper customer acceptance testing procedure in its appendices. Run it before deploying your autonomous penetration testing tool. Verify that scope boundaries hold under test conditions, that kill switches respond within the SLA windows defined in  

APTS-SC-009, and those findings include the confidence scores and evidence chains required by the reporting domain. 

This will give the security team confidence to run autonomous pentesting tools on various sensitive environments without fear.

How to Implement APTS Framework

If you are building an autonomous penetration testing platform and treating APTS as something to bolt on after the product is done, you are already carrying technical debt you have not counted yet.

Retrofitting APTS into a fully autonomous system is costly, and the likelihood of rogue agents becoming rogue is very high. The right time to map your platform against APTS is before a line of architecture is drawn.

Here is a step-by-step sequence to do it properly.

Step 1: Get your team aligned on tiers before anything else.

Get your engineering leads, security architects, and product management into the same room with the standard before design begins. Map your product’s intended capabilities against the three tiers and decide which one you are building toward. This is a product decision, not an engineering one, and making it late is expensive.

For example, if you build without declaring a tier, you will eventually need to bolt controls onto a finished product to meet a customer’s procurement checklist. That just obscures the security gap until an incident surfaces.

Step 2: Build the audit infrastructure first

Auditability is the foundation of APTS and is referenced by every other domain. Every significant event, like kill switch activation, requires logging with a timestamp and context. Without functioning Auditability, no other domain can prove its safety controls were operational or that requirements were met.

APTS-AR-020 mandates that the audit trail be stored on infrastructure that agents cannot access. If you implement scope enforcement, safety controls, and human oversight before designing the audit layer, you have no way to verify that they are working.

Step 3: Understand cross-domain dependencies

APTS domains are interdependent. A single event could trigger the requirements across 4 or more domains simultaneously.

For example, during the exploitation phase, the kill switch must be activated immediately upon any indication of service degradation caused by the testing. 

Throughout this entire process, the following controls must be actively enforced per the APTS framework:

• SC-010 – Health check monitoring
• SC-007 – Cumulative impact tracking
• AR-001 – Structured event logging
• HO-015 – Multi-channel operator notification
• SC-016 – Evidence preservation
• SE-023 – Credential lifecycle management
• SC-015 – Post-test integrity validation

If you implement and test domains in isolation, you will only discover these cross-domain chains during an incident.

Step 4: Implementing human oversight

Most teams treat human oversight as an alert, but APTS treats it as an operational interface with hard SLA ceilings.

APTS-HO-002 clearly defines what the operator dashboard must display and how often the information there should be updated. APTS-HO-003 sets 15-minute response windows for exploitation and lateral movement decisions and an immediate kill-and-preserve response for legal triggers.

Step 5: Audit your platform against the verification

Every APTS requirement includes verification criteria that define exactly what evidence a reviewer or auditor needs to confirm that the control exists and works. Before you call a domain complete, test each requirement against its own verification criteria, not your internal interpretation of it.

For example, APTS-SC-019 containment is achieved by attempting to cross the sandbox boundary.

Pro Tip: Work through each domain’s verification criteria as a structured test plan. The gaps you find there are the gaps your customers and auditors will find later. Find them first.

How Astra’s Autonomous Pentest Platform Aligns with APTS

At Astra Security, our Autonomous Pentest Platform was engineered with the core principle that advanced offensive autonomy must remain strictly governed by auditable controls. Designed in alignment with OWASP APTS requirements (SE, AL, SC, AR, RP, HO, MR, TP domains), the platform orchestrates coordinated multi-agent systems that simultaneously run structured methodology-driven pentests and heuristic Bounty Hunter agents. 

Structured agents perform exhaustive surface enumeration and testing per established frameworks, while Bounty Hunter agents dynamically pursue high-utility attack paths beyond static threat models, with real-time Scope Enforcement (SE) and Graduated Autonomy (AL) guardrails preventing any out-of-bounds activity.

To tackle false positives, after agents identify potential issues, an independent validator agent executes controlled, non-destructive exploit validation to confirm true positives. This baked-in dual-agent pipeline produces reproducible evidence chains, calibrated confidence scores, and safe Proof-of-Concept demonstrations without impacting production data or systems. 

Every surfaced finding meets APTS Reporting (RP) and Auditability (AR) standards for verifiable, enterprise-grade results. 

Final Thoughts

APTS matters because it converts an abstract question, “Can we trust this autonomous pentesting tool,” into a structured, auditable, contractually referenceable answer.

The standard defines 173 requirements across eight domains, three conformance tiers for governance maturity, four autonomy levels for operational latitude, and four asset criticality categories for risk calibration. Those components together form a decision framework that applies equally to the CISO setting procurement policy, the engineer building the platform, and the auditor verifying the claim.

For organizations building or procuring autonomous pentesting capability, the right starting point is the OWASP APTS Getting Started guide.

The full standard, checklists, Vendor Evaluation Guide, and Conformance Claim Template are all in the OWASP/APTS GitHub repository. The standard is open, version-controlled, and free. The only cost is understanding and implementing it.

OWASP APTS FAQs