In-process libraries
Pass the validator result from the point in your code where you already handle it.
Integrations, runtime guardrails
When a guardrail blocks something, send it to someone who can decide
Guardrails catch harmful output and risky requests. On their own, a block usually ends the work, so teams keep the agent on a short list of safe tasks. Send the guardrail result with a VeriProof policy check and your rules decide what comes next. Most blocks stay blocked, and the ones that need judgment reach a person with authority, so the agent can take on harder work.
A flagged claim reply, handled
An insurance agent drafts a reply to a customer asking whether surgery is covered. The guardrail flags it as possible medical advice and blocks the draft.
Without a next step, the customer waits and someone eventually notices. With VeriProof, the application sends the guardrail result along with the claim facts, and your rule says flagged coverage replies go to a licensed adjuster. She's notified in Slack or by email, opens the case in VeriProof to see the draft, the flag, and the policy details, checks the wording against the policy, and approves it. The customer hears back the same day, and the record shows the flag, the rule, and her decision.
Works with the guardrail you already run
Guardrail APIs
Send the verdict and reason the API returns, along with the business facts of the request.
Your own policy service
Keep your internal rules engine or model gateway, and pass along the structured result it returns.
Keep Lakera or Guardrails AI. Add routing and the record.
Both are good at the job they were built for, and VeriProof doesn't do that job. It doesn't detect prompt injection or scan content.
Lakera, now part of Check Point, screens prompts, tool use, and responses for prompt attacks, data leakage, and harmful content. A flagged request comes back marked as flagged, and Lakera's docs leave the next step to your application. That's where the VeriProof call goes.
Guardrails AI is an open-source framework that runs validators on what goes into and comes out of the model. When one fails, you choose what happens: fix the output, re-ask the model, refuse, or raise an exception. Pass the validator's name and result to VeriProof alongside the request.
What reviewers see later
Which control applied
The guardrail's reason and rule version sit next to the VeriProof rule that decided the next step.
Who decided
When a person reviews the case, their response and rationale stay with the action they covered.
Only the content you choose
Raw prompts aren't always needed. Redact sensitive content before it leaves the application, and choose which fields to keep and for how long.
A record they can check
Each record is sealed. An outside reviewer can confirm it hasn't changed, with no VeriProof account and no need to trust us. See how evidence integrity works.
Frequently asked questions
No. Keep it. VeriProof works with the result your application sends.
With a core SDK for TypeScript, Python, .NET, Java, Rust, or Go, at the point where the application handles the result. Start with the SDK quickstart. Signed-in developers can also find it under Tools and SDKs in the customer portal.
Return one of five decisions: Allow (continue as submitted), Warn (continue with a warning), Transform (continue with a corrected version), Escalate (wait for a person with authority), or Deny (stop). An escalated case goes to the reviewer your settings name. Reminders go out, and overdue work escalates.