# OWASP APTS: a governance standard for autonomous penetration testing

> APTS is an OWASP incubator project that specifies what an autonomous penetration testing platform must do before it is allowed to act: 173 tier-required requirements across eight domains, from scope enforcement to manipulation resistance. It is a document, not a tool, and it has no certification body, so its value depends entirely on how a buyer writes it into a contract.

**OWASP/APTS** — OWASP Autonomous Penetration Testing Standard

- Repository: https://github.com/OWASP/APTS
- Website: http://owasp.org/APTS/
- Stars: 700 · Forks: 89
- Language: Python
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/owasp-apts

## A standard that governs platforms, not testers

OWASP 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, and the definition is deliberately wide: it covers platforms delivered by vendors, operated as a service, and built in-house by enterprise security teams testing their own organisation.

The important boundary is stated in the second paragraph of the README. APTS is not a testing methodology. It complements PTES, OWASP WSTG and OSSTMM, and it does so by addressing the problems that are unique to autonomous operation: scope enforcement, safe autonomy, manipulation resistance and accountability.

That framing explains why a standard exists at all here. A methodology tells a human tester what to try. An autonomous platform decides on its own what to try, at what speed, against which targets, and it may change the state of the system it is testing. The four problem areas the README names are the four ways that goes wrong. A platform that does not enforce its scope will test something you did not authorise. A platform with no safety classification will fire an exploit that takes down a production service. A platform that can be manipulated by its own input can be talked into widening its scope. A platform with no accountability cannot tell you afterwards what it did.

The project is an OWASP Incubator Project, at version 0.1.0, with a badge inviting contributions and a Slack channel for discussion. The licence is CC BY-SA 4.0, which is a documentation licence and fits a standard that is meant to be copied, translated and reused.

## Eight domains and the requirements inside them

The standard is organised as 173 tier-required requirements across eight domains, each with a two letter prefix that becomes part of the requirement identifier.

Scope Enforcement, prefix SE, has 26 requirements and covers defining, validating and enforcing testing boundaries. Safety Controls, SC, has 20 and covers impact classification, blast radius, kill switches, rollback and an execution sandbox. Human Oversight, HO, has 19 and covers approval gates, dashboards, escalation and operator qualifications.

Graduated Autonomy, AL, has the largest count at 28 and defines four autonomy levels, from L1 Assisted through L4 Autonomous. Auditability, AR, has 20 and covers logging, decision trails, evidence integrity and audit trail isolation. Manipulation Resistance, MR, has 23 and covers prompt injection, adversarial inputs and scope widening defence. Supply Chain Trust, TP, has 22 and covers AI provider trust, data handling, multi-tenancy isolation and foundation model disclosure. Reporting, RP, rounds it off with 15 requirements on finding validation, confidence scoring and coverage disclosure.

The distribution is itself a statement about where the difficulty lies. The three domains that deal with an autonomous system acting on its own, safety, oversight and autonomy levels, come to 67 requirements, more than a third of the total. Scope enforcement and manipulation resistance, the two domains that deal with an adversary trying to steer the system, add another 49. The domain that deals with the model underneath the platform, supply chain trust, has 22, which is a signal that the standard treats the model provider as part of the system being governed rather than as a vendor to be trusted implicitly.

Each domain lives in its own directory under the standard/ folder, with a README, and the domain structure is what an assessor works through.

## Three tiers and what a lower one still guarantees

The compliance structure is cumulative and the floor is not trivial. Tier 1, Foundation, is 72 requirements. The platform will not test outside scope, it can be stopped immediately, and it provides an audit trail. Those three properties are the whole point of the standard, and the fact that they are the baseline rather than an aspiration is the part worth noting.

Tier 2, Verified, adds 85 requirements for a cumulative 157. The additions bring full transparency, tamper-proof audit trails and independently verifiable findings. The word independently is doing work: at Tier 2 the findings are meant to be checkable by someone who does not trust the platform.

Tier 3, Comprehensive, adds 16 more for a cumulative 173, and is described as the highest assurance for critical infrastructure and L4 autonomous operations. Sixteen requirements for the top tier is a narrow band, which is sensible if the earlier tiers have already done the structural work.

There is a fourth category that is easy to overlook. Twenty additional advisory practices live exclusively in an Advisory Requirements appendix under the APTS-<DOMAIN>-A0x identifier pattern. Advisory practices are not counted toward any tier and do not affect conformance, so a document can contain them without changing the compliance arithmetic.

The reference format is designed for procurement. Requirements use the format APTS-XX-NNN where XX is the domain prefix and NNN is the requirement number, for example APTS-SE-001, and for versioned references in contracts or evaluations the version is inserted, giving APTS-v0.1.0-SE-001. That versioning is the difference between a standard you can cite and a standard you can argue about.

## No certification body, and what that means for a buyer

The most consequential sentence in the README for anyone considering this standard is the one about governance. APTS has no certification body, no mandatory third-party audit and no fee. Platforms are assessed against the requirements and conformance is documented. The standard does not prescribe who performs the assessment: internal self-assessment, independent internal review and external third-party assessment are all valid, and the choice is left to the reader.

This is a deliberate design choice, and it cuts both ways. On the positive side, there is no body that can be lobbied and no certificate that means only that someone paid a fee. A conformance claim backed by an evidence package that a customer's own security reviewer has checked is worth more than a badge. On the negative side, a claim of Tier 2 conformance means whatever the assessment behind it was worth, and the buyer has to do the work of judging that, which is exactly the work the standard's templates are designed to support.

The repository carries a set of documents for that work. There is a Conformance Claim Template, an Evidence Package Manifest, a Vendor Evaluation Guide, an Evidence Request Checklist, Checklists, and a Customer Acceptance Testing document. The Evidence Package Manifest and the Evidence Request Checklist are the pair that a procurement lead would actually use, since they define what a vendor must hand over and what to ask for.

The README is explicit that the reader path table it provides is informative only, and that it does not create or modify any APTS requirements. The same restraint applies to the standard as a whole: it defines what conformance would mean and leaves the judgement to the parties involved.

## Which document to open depends on who you are

Because the standard has eight domains, three tiers and a set of appendices, the README includes an orientation table that maps a role to a starting point, and it is worth taking at face value rather than reading the standard front to back.

Someone new to APTS starts with the Introduction and the Glossary, then uses the Getting Started guide, and the outcome is understanding the framework and its scope. A vendor or platform builder reads the same two documents, then the Checklists for their target tier, and then works through the domain READMEs and Implementation Guides with the Conformance Claim Template and the Evidence Package Manifest, producing a documented conformance claim and an evidence package.

An enterprise internal team goes from the Introduction and Glossary to the Getting Started guide and then into the core domains, which the table names as SE, SC, HO and AR, plus the templates, and the outcome is an internal governance baseline. That list of four is a useful signal: if you run an autonomous platform inside your own environment, scope, safety, oversight and auditability are the four domains that will decide whether you can turn it on.

A CISO or procurement lead goes to the Vendor Evaluation Guide and then to the Evidence Request Checklist, the Evidence Package Manifest and a conformance claim, with a vendor evaluation decision as the outcome. A security reviewer or auditor reads the claimed tier and the Checklists, then works through the domain verification sections and Customer Acceptance Testing, producing independent review findings.

The structure tells you how the standard is meant to be used. It is not a checklist to run against a tool, it is a document to argue with a vendor about, and the appendices carry the templates for that argument.

## What a standard at version 0.1.0 can and cannot do

The first limitation is the version. The project is at 0.1.0, which by the project's own numbering is a first draft. The standard has no GitHub releases, so there is no packaged artefact, and the last push to the repository was on 2026-09-03, with the repository not archived. The project is an OWASP Incubator Project, which is the stage before a project graduates with a chartered status, and the practical effect is that the content can change.

The second limitation is the scope of what a standard can enforce. APTS defines requirements and, by its own account, is not a methodology, so it does not tell you how to scope a test, how to exploit anything, or how to validate a finding technically. If your problem is that your testers are not thorough, this document will not fix that. It addresses the governance of systems that act on their own, which is a narrower and, for many organisations, more urgent question.

The third limitation is that conformance is a claim. With no certification body, a vendor can publish a conformance claim, and a buyer has to verify it. The standard helps by producing the artefacts that make verification possible, but it cannot make verification happen, and it cannot tell you whether a vendor's self-assessment was honest. The Customer Acceptance Testing document exists precisely because that step is left to the parties.

The alternative is not another standard, it is a contract. A single procurement team can write the scope boundaries, the kill switch requirement, the audit retention period and the autonomy ceiling into a master services agreement without adopting APTS at all, and for a one-off purchase that may be simpler. The difference in approach is that APTS gives you a shared reference model with identifiers you can cite, a tier structure to talk about levels of assurance, and evidence templates that make the conversation concrete, while a contract gives you enforceability in one instance and nothing transferable. The second is stronger, the first is reusable, and for organisations running several autonomous tools against each other the reusable model is usually the more valuable of the two.

## Conclusion

Adopt OWASP APTS if you are buying, operating or building an autonomous penetration testing platform and you need a shared vocabulary for scope, kill switches, autonomy levels and evidence, because the requirement identifiers are designed to be quoted in a contract. Do not adopt it as a testing methodology, because the document says outright that it is not one, and do not expect a badge or a certificate, since there is no certification body, no mandatory third-party audit and no fee. Before you use it, read the domain you actually need, which is usually scope enforcement, safety controls and human oversight, and check that the requirements still match the platforms you are evaluating, since the standard is at version 0.1.0 and carries a translation and revision process of its own.

## FAQ

### What is OWASP APTS?

It is a governance standard for autonomous penetration testing platforms, defining what those systems must do to operate safely, transparently and within defined boundaries, whether they are delivered by vendors, operated as a service or built in-house. It is an OWASP Incubator Project at version 0.1.0, licensed CC BY-SA 4.0.

### How many requirements does APTS have and how are they organised?

There are 173 tier-required requirements across eight domains: Scope Enforcement with 26, Safety Controls with 20, Human Oversight with 19, Graduated Autonomy with 28, Auditability with 20, Manipulation Resistance with 23, Supply Chain Trust with 22 and Reporting with 15. Twenty further advisory practices sit in an appendix and do not count toward conformance.

### What are the APTS compliance tiers?

Tier 1 Foundation is 72 requirements and covers not testing outside scope, being stoppable immediately and providing an audit trail. Tier 2 Verified adds 85 for a cumulative 157 with full transparency, tamper-proof audit trails and independently verifiable findings, and Tier 3 Comprehensive adds 16 more for a cumulative 173, aimed at critical infrastructure and L4 autonomous operation.

### Does APTS have a certification body or cost?

No. The README states that APTS has no certification body, no mandatory third-party audit and no fee. Platforms are assessed against the requirements and conformance is documented, and internal self-assessment, independent internal review and external third-party assessment are all valid approaches.

### How are APTS requirements referenced in a contract?

Requirements use the format APTS-XX-NNN, where XX is the domain prefix and NNN the requirement number, for example APTS-SE-001. For versioned references in contracts or evaluations, the version is inserted, giving APTS-v0.1.0-SE-001.

## Sources

- [Issues](https://github.com/OWASP/APTS/issues)
- [OWASP/APTS on GitHub](https://github.com/OWASP/APTS)
- [Project website](http://owasp.org/APTS/)
- [README](https://github.com/OWASP/APTS/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/owasp-apts