Trust and security

One authorization choke-point, default-deny

Exactly one path leads from wanting to run a technique to running it, and every caller — the planner, the API, an external agent — goes through it. Absence of authorization is a refusal plus an audit entry, not a warning and not a soft block. The check is enforced in the engine, never in a license agreement, and it is never bypassable and never part of a paid tier.

A grant is an Ed25519-signed engagement authorization: its scope of targets, the safety classes it permits, a time window, rate ceilings, and requester and approver identity. The private key stays in OpenBao Transit and never leaves it; verifying a grant needs only the public key pinned on it, so enforcement stays local and works offline. Every dispatch re-checks the live grant, so a revoked or expired grant is rejected on the next call, not honored from a cache.

Safe-mode taxonomy: proof, not payload

Every technique carries a declared safety class, checked at load and again at dispatch against the grant's allowed classes. A misdeclaration is refused, not trusted.

• passiveOn by default

  Observation only — banner, version, and configuration inference, with no change to the target's state.

• active-safeOn within an allowing grant

  Crafted, non-destructive input that proves a condition by evidence, not effect: reads a planted canary, or makes the target call an operator-controlled out-of-band beacon to prove reachability. Never a shell, a write, persistence, exfiltration, or anything that could reduce availability.

• active-intrusiveOff, interface-only

  State-changing or availability-impacting techniques. Interface-only in this build, not shipped in the standard artifact, and refused without a two-person-approved grant.

Intrusive capability is isolated

No working intrusive technique is authored in this repository, in any release. A guardrail test fails the build the moment a Go file appears in the restricted intrusive package, and a second test scans all shipping code for anything that grants a clearance outside the choke-point. An intrusive grant additionally requires a second, distinct approver — there is no single-admin path to it.

The guardrails are never paywalled and never sold around: scope enforcement, safe-mode classification, the audit log, blast-radius governance (concurrency and rate caps, an allowed-window scheduler, a target-health circuit breaker, and a global kill switch), and signed provenance all ship in the free tier.

Threat model, honestly

A threat model that only lists mitigations is not one. These are the assets Assay protects and the limits it does not pretend to close.

What Assay protects

• Your own target systems. The largest risk the product introduces is becoming the thing that harms what it was hired to test, so blast-radius governance is always on and cannot be turned off — an operator can only make it stricter.
• Engagement data — scope definitions and target lists, which reveal what you consider sensitive.
• Evidence bundles — each is proof that a specific exposure is exploitable, so each is treated as sensitive.
• The Ed25519 signing key — the root of trust for every grant, held in OpenBao Transit.
• The hash-chained audit log — the append-only record that every action ran within its declared scope and safety class.

Where the limits are

• A fully compromised host still cannot dispatch new validation without a valid signed grant, and ships no working destructive technique to run — but it can read data already at rest on that host. Encryption at rest is your infrastructure's job, not this layer's.
• A community adapter runs in the engine's process with no sandbox. Its declared class is enforced, but honest behavior within that class is a matter of code review before you install it, not a runtime boundary. Treat every adapter's source as a real question.
• Whoever holds the authz private key can forge grants that verify. OpenBao's own hardening — unseal discipline, narrow token scope, snapshot access control — is load-bearing for this model, not a separate concern.

Build integrity

Release images are cosign-signed, and each ships with a software bill of materials (SBOM) and SLSA build provenance, so you can verify what you run before you run it. Dependencies are pinned, and govulncheck, Trivy, and an SBOM scan run in the build pipeline. Images are mirror-able for an air-gapped install, and the product makes no runtime call to any vendor endpoint.

Reporting a vulnerability

Guardrail bypasses, choke-point escapes, and safe-mode misclassifications are treated as critical. Report a suspected vulnerability privately, never through a public issue, so a fix can ship before the details are public.

The security contact and the full disclosure policy ship with the source, in the repository's security policy (SECURITY.md).