it is a wednesday in november. a CISO at a series C SaaS company opens her phone and watches a competitor get popped on twitter — a trivial auth bug, a screenshot of customer data, a thread that already has two thousand reposts. she walks to her head of AppSec and asks how often the product gets tested end-to-end by someone actively trying to break it. the answer is “annually, by a consultancy.” the last report was in march. it is now eight months old. the product has shipped four hundred and thirty-two pull requests since.

the gap nobody sells into

the standard answers do not fit the shape of the problem.

annual pentests are a snapshot. by the time the report lands, half the reviewed surface has been refactored and a quarter of it no longer exists. continuous DAST scanners produce noise that the security team spends most of its week triaging and eventually mutes. bug bounties find what hunters happen to look at, when they happen to look, filtered through the ones who bother with a program that is not facebook. managed pentest-as-a-service platforms mostly sell a nicer dashboard on top of the same quarterly human engagement.

the continuous, exploit-validated, audit-ready offensive testing program — the kind a security-conscious 500-person company actually wants — does not exist as a buyable product. so the CISO keeps signing the annual SoW and hopes her product is not next week’s screenshot.

pwnkit cloud

pwnkit cloud is an autonomous AI attacker on contract, pointed at a single product and run continuously.

the engine runs a discover-attack-verify-report pipeline that outperforms commercial pentest teams on the public XBOW benchmark. every reported finding arrives with a working proof of concept, an independent verification pass from a second agent that was never shown the first agent’s reasoning, and a full evidence chain the security team can read, reproduce, and hand to an auditor.

single-tenant. founder-led. zürich, switzerland. closed beta, by application.

it is not a self-serve scanner, not a chatbot wrapped around a burp report, not an SDR-led sales motion, not a black-box vendor that hands back a PDF and a handshake.

why closed, why apply-only

every engagement is reviewed by the people who built the engine. that is the constraint. it is the reason the roster is small and the reason most inquiries do not become engagements.

the fit is narrow on purpose. the right customer already has an internal security function, already knows what a CVSS vector means, already has opinions about the last firm they hired, and is looking for something that closes the continuous-coverage gap without adding a third vendor to an already-loud dashboard. the wrong customer wants a compliance checkbox and a cheap one. the application form exists so both sides figure out which conversation this is before anyone signs anything.

the buyer who is right for pwnkit cloud will recognize themselves in that paragraph.

how it runs

a few concrete posture statements that describe how an engagement actually looks from the customer side.

single-tenant. each engagement runs in an isolated environment. no shared model context, no cross-customer telemetry, no data leaving the tenancy except the finding payload the customer explicitly receives.

exploit-validated only. every finding carries a reproducible proof of concept. a second agent re-runs the exploit from scratch before the finding is released. anything that cannot be reproduced is killed, not downgraded.

audit trail by default. every agent action, every request, every decision is logged to an immutable evidence chain. the customer’s auditor gets the same view the founder does.

methodology you can read. the attack methodology is not a trade secret. the security team gets access to the same playbooks the agents run and can ask for additions, exclusions, or custom scopes before an engagement starts.

no dashboard theater. findings land as a signed report, a SARIF feed into the customer’s existing pipeline, and a direct channel to the person responsible for the engagement. that is the entire surface.

the open-source roots

the engine has open-source roots. the CLI that powers the discovery and verification layer is public at github.com/PwnKit-Labs/pwnkit, under the same methodology the cloud product runs. security teams who want to read the code before they trust the output are encouraged to do exactly that. the cloud product is what turns the engine into a managed, single-tenant, contract-backed program — not a different engine.

applying

the form lives at /cloud/contact. it is short. it asks what the product is, what the security function currently looks like, and what the customer is actually trying to buy.

every application gets a response from a human within five business days, or not at all. there is no drip sequence, no follow-up from a sales platform, no newsletter enrollment. the roster is small and the review is careful. that is the design.

the CISO in november did not have a product to call. this one is now open, quietly, to the teams that recognize the shape of the problem.