Proof of Threat without exploitation.

The doctrine

Labs does not test credentials it finds. Labs does not probe infrastructure declared by the client or the client's vendors. Labs does not run exploits, even harmless ones, even on engagements that authorise them. The boundary is intentional and documented; the engagement is scoped around it from the first call.

The doctrine has a name on the methodology page: Proof of Threat, not Proof of Exploitation. This article explains what that means in practice, why we hold the line, and how the impact statement in a deliverable remains defensible without the test.

What an attacker actually does

It helps to start from the adversary's side. An attacker who finds a leaked credential in a public artefact will not, in most cases, run an exploit chain. They will:

1. Confirm the credential's format matches a live class (regex check).
2. Test the credential against the relevant API with a benign metadata call (sts:GetCallerIdentity or equivalent).
3. Enumerate the principal's permissions.
4. Walk the dependency graph of those permissions to identify a high-value action.
5. Decide whether to act, sell the access, or hold for later.

Steps 1, 3, and 4 are entirely read-only. The attacker's attack is mostly enumeration. Exploitation is the last step in a sequence whose first 80 % is observation.

This matters because it means an audit firm can construct the same chain — minus step 2 — and arrive at a near-identical impact statement, with the same evidential weight as a thoughtful attacker's reconnaissance. The chain is the impact. The execution is the consequence.

The four-step construction

A Labs Proof-of-Threat card, as it appears in a Board-Ready deliverable, is constructed in four steps. None involves a probe.

Step 1 — Identify the credential class. A regex and entropy check, combined with a registry-format match, classify the credential to a specific class (AWS IAM access key, Stripe restricted key, GitHub personal access token, etc.). The classification gives the read surface.

Step 2 — Identify the declared use. Search the client's public artefacts — repositories, workflow files, IaC modules, deployment manifests — for references to the credential or to its declared principal. The references give the public statement of what the credential is intended to do. The intention is publicly declared; reading it is reading the surface, not probing it.

Step 3 — Construct the permission graph. From the declared use, build the permission graph that the credential's principal would have if the declaration is accurate. The graph is reasoned from public information (Terraform modules, CloudFormation templates, public IAM role declarations) plus reference knowledge of the relevant cloud's permission model.

Step 4 — Reason the impact. Given the constructed permission graph, write the impact statement. "If the credential is active and the role declaration is accurate, the principal can perform actions X, Y, and Z, with the consequence W." The statement is explicitly conditional. It says what an attacker can do if the public declaration matches reality.

Why this is enough

The implicit objection is that step 4 contains the word "if." A probing test would remove the "if."

The objection is correct technically. It is wrong commercially and contractually.

Commercially, the buyer hires Labs specifically for the audit-trail clarity that no probe leaves behind. If we tested credentials, the test would appear in the buyer's account log. The audit would not be invisible. The buyer wants invisibility because they want to know what an attacker can see without authorisation, not what their security team will see when we probe.

Contractually, the boundary is hard. The Labs contract explicitly forbids active testing. The boundary is a feature of the product, and the product would be a different category if we crossed it.

Adversarially, a serious adversary makes the same conditional statement Labs does. They do not test before deciding to act, because tests are detectable. They reason the chain, decide it is real with high probability, and act once. The impact statement Labs produces is equivalent in epistemic weight to the impact statement a careful adversary produces. Both contain the "if."

What we do instead of probing

The substitute for the probe is the AI-Alliance Challenging applied to the impact statement.

For each Proof-of-Threat card, the four models read the constructed chain and produce a verdict: is the impact statement defensible from the declared facts. The disagreements are steel-manned; the founder adjudicates. The Challenge Log appendix shows the dissent.

The result is not "as confident as a probe." It is "as confident as a careful adversary." The confidence level is honest; the deliverable does not over-claim.

Where the doctrine fails

Three engagement types where Proof-of-Threat without exploitation is insufficient, and where Labs declines or refers the engagement:

1. Authorised red-team simulation. A buyer who specifically needs an authorised offensive engagement — a penetration test under contract, with a written scope and a defined target — is buying a different product. Labs refers these to partner firms. The partner signs the test; Labs does not.

2. Incident response confirmation. A buyer who has reason to believe a breach is currently active needs incident response, not audit. The doctrine of non-probing is inappropriate when the answer to "is this active right now" must be definitive. Labs refers these to IR specialists.

3. Vulnerability validation for disclosure. A researcher who needs to confirm a specific CVE in a specific vendor's product, for responsible disclosure, needs to validate. Labs does not do this work.

In all three cases, the referral is explicit and the partner is named. The doctrine is preserved by referring out the engagements that require its opposite.

What the buyer should ask

A prospect evaluating whether Labs is the right firm for their need can ask the following during the first call:

• "Will you test the credentials you find?" — Answer: no. Ever.
• "Will you probe my infrastructure?" — Answer: no. Reading public declarations is not probing.
• "Will my account log show your audit?" — Answer: no. The audit is invisible to your monitoring.
• "What if I want exploitation testing?" — Answer: we refer to a partner. We name the partner. We do not sign the test.
• "How do you make the impact statement defensible without the test?" — Answer: the AI-Alliance Challenging applied to the constructed chain, with the Challenge Log appendix.

If those answers are wrong for the buyer, the buyer should choose a different firm. The market has good firms for the other categories. Labs is for the buyer who wants the discipline of non-probing as a contractual feature.

A note on the long-term

The doctrine of Proof of Threat without exploitation is older than Labs — it is the boundary that audit firms in regulated jurisdictions (financial audit, accounting, formal verification) have held for a century. Cybersecurity has occasionally pretended this boundary does not apply to it. It does. The firms that hold the boundary will be the firms whose attestations regulators eventually require. Labs is positioned for that eventual requirement.