Skip to content
Ratify Protocol Ratify Protocol

Verify pilot workflow

Ratify Verify is currently an alpha product. A pilot is a scoped design partnership around one consequential action, not a promise that every surface or compliance control is generally available.

Start without a sales gate

Section titled “Start without a sales gate”

Use the open Ratify Protocol and SDKs first. Reproduce an allow and the important denials locally, without a Verify account. Then create a personal Verify sandbox to run the same operation through the managed endpoint and inspect the decision record.

The pilot is the bridge between those two experiences: it tests whether Ratify changes a real authorization boundary in your product.

The pilot sequence

Section titled “The pilot sequence”
  1. Choose one receiver boundary. Pick the API, MCP tool, A2A route, or other handler where an unauthorized agent would create a meaningful operational or financial consequence.
  2. Name the operation. Define the action, resource, requested path, payload digest, and required scope. The operation digest must be canonical and reproducible by both sides.
  3. Register the receiver. Create a receiver integration in Verify and keep its API key on the receiving service. The receiver requests a fresh challenge for each protected invocation.
  4. Present a proof. The agent signs the challenge with a Ratify SDK and presents the proof bundle with the operation context, workspace, and agent binding.
  5. Enforce the decision. The receiver calls POST /v1/ratify/verify before the handler. Only an explicit allow reaches the protected action. Denials and service failures must remain fail-closed and must not invoke the handler.
  6. Inspect the evidence. Fetch the decision receipt and verify that the receipt bytes reproduce the returned hash. Keep the decision, reason, operation, and handler result together in the pilot notes.
  7. Run the adversarial gate. Demonstrate denials for the wrong authority, wrong resource or scope, expired proof, revoked proof, replay, and invalid presenter. Record that no protected side effect occurred for each denial.
  8. Decide the next boundary. Continue with Verify Operational, scope a Trust design partnership for stronger evidence requirements, or evaluate Sovereign when deployment control and residency are the primary constraints.

What to bring to a pilot

Section titled “What to bring to a pilot”
  • The protected operation and its current authorization path.
  • A receiver owner who can change the enforcement middleware.
  • One agent or agent platform that can present a Ratify proof.
  • The required scope and the resource identifiers that must be bound.
  • A test environment where allow, deny, replay, expiry, and revocation can be observed safely.
  • The evidence and incident questions your security or compliance team needs answered.

What the alpha does and does not claim

Section titled “What the alpha does and does not claim”

The alpha provides managed Agentic API verification, hosted revocation checks, delegation controls, usage metering, and decision records. The receiver remains responsible for enforcing the result and protecting its API key.

Conversational AI, additional meeting adapters, Physical AI managed integrations, signed Trust evidence packages, and Sovereign deployment packaging are scoped through design partnership or roadmap work. Do not treat the pilot as a certification, a SOC 2 or ISO report, or proof of a live WORM/KMS deployment unless that exact control has been tested in your environment.

Continue

Section titled “Continue”