Human Review security and shared responsibility

VeriProof checks who can review a case. Your application controls whether the approved action runs. Neither may proceed when its required checks fail. A delivered message does not grant permission, and a signed outcome does not prove execution.

Authorization boundary

VeriProof authenticates the employee and checks their access when recording each decision. Checks cover the tenant, application, assignment, role, group membership, required capability, and separation rules. A role past its end date gives no authority. When separation of duties is on, an application owner can decide only as the confirmed sole eligible reviewer, and the decision records it.

Customers are responsible for maintaining current users, assignments, recovery administrators, and identity-provider access. Provider group membership, mailbox access, a notification webhook, or possession of an application credential does not grant review authority.

Application boundary

The application owns the checkpoint and protected side effect. It must:

• store the checkpoint and withheld output before requesting review;
• protect the continuation store with least privilege;
• bind each pause to one workflow instance, branch, continuation, generation, and state fingerprint;
• validate every outcome binding after signature verification;
• use an atomic claim so a duplicate cannot repeat the action;
• re-evaluate current application state and current VeriProof policy before any advancing branch resumes;
• keep rejection, cancellation, and expiry from releasing the work; and
• report its resulting state through the separate acknowledgment.

Your application team owns the callback listener, durable store, queue or worker, and revision path. The listener verifies and stores the delivery. It must not call an agent, resume a workflow, or run a protected tool within the HTTP request.

Callback endpoint protection

The customer application team provides the public HTTPS receiver outside the environment-gated localhost test mode.

Destination validation must reject private, loopback, link-local, redirected, and otherwise unapproved addresses. Unsupported URL schemes are rejected too.

Validate the body size, timestamp, raw-body signature, and schema. Then check that deliveryId matches the webhook-id header, and check tenant and application binding, event identity, ordering, and expiry. Treat every field as untrusted until these checks pass.

Signing keys

VeriProof signs callbacks with ed25519 keys that each deployment holds. Only the public keys leave VeriProof: they’re published at /.well-known/veriproof-webhook-keys.json on the API endpoint, so your receiver, an auditor, or your security team can check a delivery without a shared secret.

The SDK keeps the published key set for up to an hour. When VeriProof rotates keys, it publishes the new key at least an hour before signing with it, so receivers pick it up without a deployment. If you pin the key set for a host without outbound access, update the pinned copy when VeriProof announces a new key.

Review event webhooks can instead use a whsec_ subscription secret (v1 signatures). Store that secret in your approved secrets manager, keep it out of logs and screenshots, and rotate it when ownership changes.

Data protection

Keep callback payloads to the documented allowlist. Protected session evidence stays in VeriProof by default. The customer chooses lawful data, retention, residency, deletion, legal-hold, and support-access requirements. Do not place secrets, raw protected content, or full callback bodies in logs, tickets, screenshots, analytics, or collaboration messages.

The application may provide a short decision summary, typed business facts, and opaque non-secret reference labels. This is application context, not verified evidence. Do not submit URLs, portal IDs, callback IDs, session-step IDs, blob paths, credentials, signed URLs, raw tool arguments, prompt history, or hidden reasoning. VeriProof derives policy and captured-session evidence from the bound case and reveals it only after the relevant authorization checks.

A callback may include application-visible typed answers, permitted replacements and feedback, and the exact profile, request, response, payload, and editable-scope bindings. It must not include reviewer identity, the private review note, raw evidence, prompt history, chain-of-thought, checkpoint data, the protected payload, credentials, secrets, or unrelated reviewer context.

Permitted payload changes are replacements, not an editing language. Accept only replace for a registered JSON Pointer path after its value kind, classification, protected-payload digest, and editable-scope digest match. Reject root replacement, unknown or sensitive paths, executable expressions, tool-name changes, and every other operation. Apply a validated replacement to the application’s local copy; never reconstruct the protected payload from the callback.

Receipt and execution boundary

Return a durable receipt only after the verified delivery is stored atomically. That receipt does not say that an agent, workflow, or protected tool ran. Signal an application-owned worker, claim protectedActionId atomically, and record the result with the side-effect idempotency marker. Send the separate execution acknowledgment only after the application knows whether the branch resumed, terminated, remained paused, was superseded, or failed.

Shared incident response

Release evidence

This page explains the controls and who maintains them. For assessment results, service commitments, or approval to use real data, consult the current approved evidence package.