Pillar 03 — AI-Augmented PTaaS Lane

Status: design and roadmap, not yet shipped — and the cover says so, not the fine print. The Pillar 02 register and validation gate are live and dogfooded on a 116-asset estate. Pillar 03 is the next lane, built to plug into it. This is the honest blueprint — real, sourced and buildable today — published before the build, because the discipline matters more than the tool. Free updates as it moves from design to dogfooded build.

Pillar 02 finds patterns. Pillar 03 proves bugs — an authorized, sandboxed offense lane that hands a human tester a reachable, exploitable finding (a crashing proof-of-vulnerability, or a live exploit chain) with a candidate patch, so expert time starts from proven ground rather than cold recon.

A scanner says a function looks vulnerable. A Cyber Reasoning System proves it is. It crashes the target with a generated input, or chains recon into exploit on the live app, then drafts the fix — the same loop the AIxCC systems ran at DEF CON in 2025: discover, prove, localize, patch, validate. Steal the validate step above all: an autonomous patch is only safe when paired with autonomous proof that it worked. That changes the close condition itself — "verified" stops meaning "a rescan didn't see it" and starts meaning "the proof-of-vulnerability no longer fires." A proof, not an absence of evidence.

Why this is a separate pillar. Pillar 02 is the always-on health monitor: headers, TLS, passive checks, read-only blast radius, running unattended across the whole estate every day. Pillar 03 is scheduled, consented surgery — a fuzzer that crashes the target, tooling that pops a real injection. A fundamentally different blast radius, authorized per engagement, wired so it cannot be triggered by the unattended sweep.

Two engines, picked by the shape of the target. Source-fuzzing systems are weak on CRUD web apps, and most real estates are CRUD web apps — so PentAGI is the primary engine for a web estate, with Buttercup covering native, OSS and embedded C/C++ and JVM components on a fuzzing harness. Both land in one register, both emit proven-reachable findings, both pass the same human gate.

The Rules of Engagement — the part that separates a pentest from a breach. Only manifest assets. Staging first, or tightly-scoped production with a kill switch and a change window. No destructive payloads, no data exfiltration, no test transactions. Sandboxed and egress-restricted. Per-engagement authorization, logged — who authorized, what scope, what window. If you cannot satisfy all five, you do not run the lane.

Extend the register, do not fork it. Pillar 03 reuses the Pillar 02 database, dashboard and human gate wholesale, and adds four things: a crs/pentest source carrying the crashing input or exploit chain plus the candidate patch; a second fingerprint scheme keyed on the bug-introducing commit and crash signature rather than the source line, because one defect surfaces at many locations in a fuzzing campaign; a patch-proposed lifecycle state; and an audit split that writes itself — the patch is ai_suggested, the merge is human_decided.

Honest about fit. Research-grade, not a SAST replacement. Batch economics — hours to days and hundreds of dollars per run, a scheduled deep lane and never a per-PR gate. It augments Pillar 02 rather than replacing it. And the 2026 field is crowded with 39+ AI-pentest agents, so evaluate before committing: the integration contract matters more than which tool you pick.

This is Pillar 03 of the CISO Marketplace AI Security Department. If you would rather not build it, managed PTaaS engagements run the authorized lane for you.

Practically, this assumes Pillar 02 — it extends that register rather than standing up a parallel system.