AUTHORIZED SECURITY VALIDATION

Reaper validates security under written scope and Rules of Engagement.

Reaper is available for assets the customer owns or is authorized to test. Active work begins only after the engagement documents targets, permissions, methods, operating windows, stop conditions and evidence handling — and every finding leaves evidence a defender can reproduce and a reviewer can re-check.

Public exposure

Passive review of what a surface already reveals to anyone — DNS, TLS, headers, robots, sitemap and exposed routes — without bypassing a single access control. This runs before authorization because it touches nothing it was not already shown; it maps the attack surface the way an adversary first sees it, and nothing here is active testing.

Backend and API

Within written scope: whether authorization holds, whether tenant isolation actually isolates, whether object access respects ownership, whether rate limits bind, and whether endpoints behave safely under abuse. The question is never whether a request succeeds — it is whether a request that should be refused is refused, proven with a reproducible case rather than asserted.

Repository and configuration

Client-provided or explicitly scoped source, dependency, secret, environment and build-pipeline review. The surface that leaks most quietly is the one nobody tests: a committed secret, an over-broad token, a build step that trusts its inputs. Each exposure is demonstrated against the actual repository state, not inferred from a checklist.

Agentic systems

Prompt, tool, webhook, memory, source-leakage and approval-gate testing inside an authorized environment. An agent is evaluated as an actuator: the finding is what it can be made to do outside its jurisdiction — a tool it should not reach, an instruction smuggled through untrusted input, an approval gate that can be stepped around. As agents gain authority to act, this is the surface that matters most.

Infrastructure

Named cloud exposure, routing, services and public misconfiguration within the approved target set. Third-party infrastructure stays out of bounds unless separately permitted in writing. Posture is observed and evaluated inside the boundary — what is reachable, what is exposed, what is misconfigured — and the boundary is honored in both directions.

Evidence and retest

Every finding carries its reproduction conditions, a severity, a containment or fix path, and the evidence a reviewer needs to confirm it independently. Observation is kept separable from interpretation, so a defender can walk from the raw result to the conclusion without taking the examiner's word for a step. Retest is bounded to the defined finding and its agreed remediation.

The authorization discipline a reviewer checks first

The hardest-scrutinized part of any validation offering is not the technique — it is the authority. Three rules govern every engagement before a single active probe runs.

Request is not authorization. Authorization is not testing.

A public request for a test confers no authorization. Reaper is available for assets the customer owns or is explicitly authorized to test, and active work begins only after the engagement records the targets, permissions, methods, operating windows, stop conditions and evidence handling. Anything not expressly included is denied by default.

When scope blurs, work halts.

If a target, a method, a timing window, an authority or an impact limit becomes ambiguous mid-engagement, active work stops until it is clarified in writing. A stop condition is honored the moment it is met. Ambiguity is treated as a halt, not as room to improvise.

The read-only posture is proven, not promised.

The underlying evidence tooling operates read-only by construction — it scans whitelisted paths, generates receipts, and classifies files while confirming that no deploy, delete, network call or secret access occurred. Validation produces evidence; it is engineered not to change the system it is examining beyond what the authorization permits.

Engagement requirements

  • Named domains, IP ranges, APIs, cloud resources or repositories.
  • Authority to test the target, including third-party permission where required.
  • Permitted methods, authentication contexts and production constraints.
  • Escalation contacts, stop conditions and incident procedure.
  • Evidence handling, retention, reporting and retest terms.

The finding lifecycle — scope, prove, route, retest

On authorization, an engagement runs as an ordered sequence from the authorization gate to retest closure. Each phase produces evidence a defender can use and a reviewer can re-check, so the work is accountable rather than performed on trust.

SCOPE · Authorization gate before the first probe.

The surface is mapped, then gated against the written authorization. Reachability is never read as consent; no active work proceeds without recorded scope and a named restoring authority.

PROVE · Weakness demonstrated safely, inside the boundary.

A finding is proven within the impact limits of the authorization and recorded so another operator can reproduce it, placed against a known adversary-technique matrix so a defender can act on it. The artifact carries method, not opinion.

ROUTE · Fix path recorded with the finding.

Each finding carries its fix path and the evidence behind it — receipts, hashes, logs and replayable artifacts — so remediation starts from reproducible proof rather than a narrative.

RETEST · Closure proven, not asserted.

A fix is confirmed by a scoped retest comparing before-and-after state, with the actor and the next review recorded. A residual live path keeps the engagement open; a ticket status is not closure.

The engagement does not authorize credential theft, persistence, credential stuffing, out-of-scope extraction or any testing beyond the written Rules of Engagement.

Discuss a security validation engagement