Buyer path for a security or operational review
Check the current review scope, send a non-secret fit check, and use public samples and receipt verification only where relevant.
What should a buyer inspect before starting a WitnessOps review, and what does the request form actually start?
Use this page to check the current offer, understand the first contact step, and decide whether public examples or receipt verification are useful to you.
1. Check the current review and its limits
WitnessOps delivers bounded security and operational reviews with evidence references, named limits and unresolved items. Treat View services as the live offer list; this page summarizes the current review and first-contact boundary.
The current paid review is Agent Action Security Review with a fixed fee, agreed in a signed SOW before we start. It actively tests one consequential AI-agent action in an agreed environment: attacker-controlled input, observable agent decision, tool or API execution, effective permissions, actual saved change and supporting evidence. Authorization must be enforced before the system changes. The report includes test results, demonstrated impact, reproduction conditions, mitigation recommendations and explicit gaps. Retesting can be included when the original agreement specifies its cases, window and allowance. Earlier agreements retain their accepted terms. We don't test until you give written authority. Review workflow explains the steps from enquiry to report and readout.
External Attack Surface Review is no longer available for new engagements and is not this review. Do not read the current offer as a broad AI governance program, production deployment claim, legal compliance claim, certification, or whole-environment assurance claim.
2. Send a non-secret fit check
Use Start a review when you can describe one bounded action and why it matters.
The request form is a non-secret fit check. Start with a general description. Do not send files, logs, screenshots or customer evidence during the fit check. Do not send credentials, private keys, API keys, MFA codes, recovery codes, session tokens or other secrets at any stage.
Fallback contact: engage@mail.witnessops.com.
3. Mailbox verification is not review start
After the request form, the mailbox verification step confirms mailbox access only.
The confirmation page means:
- the mailbox was confirmed for the request
- no review work has started
- no customer evidence has been accepted
- scope, fee, and evidence handling still need to be agreed
4. Agree the work before sharing material
If the situation fits, WitnessOps confirms the review, scope, authority, fee, timing and secure evidence handling before any approved, non-secret source material is accepted. Agreement on handling does not authorise sending credentials or secrets.
The engagement should make five things easy to see:
- what the situation was
- what was authorised and included
- what was checked or reviewed
- which material supports the result
- what remains limited, unknown or unresolved
5. Stop conditions
Stop the request if:
- the work cannot be bounded to one useful scope
- no approving authority can be named
- required evidence cannot be handled safely
- the goal is a broad compliance certification
- the goal is a legal audit opinion
- the request requires credentials or secrets at any stage
6. Optional: inspect public samples
Open the historical synthetic one-action package or the other agent-action examples if you want to see how a bounded action can be described. These are public illustrations, not live customer evidence or a complete sample of the current Agent Action Security Review. They do not add a signed receipt to its standard deliverables.
Read each example's limits: some explain a control path without downloadable artifacts; the CRM replay produces an unsigned demonstration receipt. The key-rotation specimen has its own sample-specific verifier, separate from receipt-only /verify.
For the pinned AI-agent public sample only, use the table below:
| Artifact | What to check |
|---|---|
ACTION_BOUNDARY.json | What the workflow was allowed to do and what stayed out of scope. |
AUTHORITY_MAP.json | Who approved, acted, observed, reviewed, or challenged the action. |
EVIDENCE_MANIFEST.json | Which evidence classes are present and which gaps are declared. |
RECEIPT.json | How approval, action, evidence, result, and limits are bound into one record. |
VERIFY_RESULT.json | What the sample verifier result reports and what it does not establish. |
CHALLENGE_PATH.md | How another party can inspect, dispute, or request stronger evidence. |
MANIFEST.sha256 | Whether sample files match the published hash manifest. |
7. Optional: understand receipt verification
Use Verify a receipt when you have supported receipt JSON to check. The public console is receipt-only v1. It can check supported receipt JSON; it does not prove the full runtime story, source-system honesty, artifact-byte revalidation, or complete bundle custody. A receipt and verifier are not standard deliverables of the current review.
An internal limited-pass maps to public indeterminate. The legacy-named public_exposure_review receipt profile retains a historical name; it does not describe the current sales offer. Its public result stays indeterminate while request, authority, workflow, manifest and artifact bytes, evidence support, signature, and production key authorization were not independently checked.
For the full procedure split (public vs offline bundle-complete), read How to Verify a Receipt.
8. Minimal buyer reading order
- Agent Action Security Review — check the current scope and limits.
- Review workflow — see what happens before and during the review.
- Start a review — submit only the non-secret fit check.
If you want to inspect public examples, continue to Sample cases. If you have supported receipt JSON, use Verify a receipt and the verification docs. A receipt result supports only the checks and limits it names.