CheckLive
Check every action before it happens.
Your AI proposes an action with its exact arguments and the evidence behind it. qbrin checks the proof first, then answers go, hold, or ask a person.
- Live today
- Proof comes from trusted state
- A receipt for each decision
Pick an action
The AI wants toRefund ₹95,000 to a customer
What qbrin checks
- We found the orderMet
- The invoice says ₹9,500, not ₹95,000Not met
- It is above your refund limitNot met
Not enough proof, so it stops. Nothing is paid.
What a check is
Three answers, asked before it acts.
The AI proposes an action. qbrin looks at the exact arguments and the evidence, then answers before anything runs.
- Go
The action may run.
The proof is current and comes from a system you trust. The action may run.
API word: ALLOW - Hold
The action stops.
There is not enough proof. The action stops and nothing happens. The reason says what is missing.
API word: HOLD - Ask a person
A person decides.
Your rules say a person decides. The AI waits for that decision.
API word: ESCALATE
In the API the same three answers are allow, hold and escalate. Every request gets one of them.
What counts as proof
No proof, no go.
An AI cannot vouch for its own action. A check counts only proof that is current and comes from a system you trust.
- Current: an old approval does not count
- About this action: proof for something else does not count
- From a system you trust: evidence the AI attaches itself is untrusted
- From your own organization: an agent from another one is refused
- The billing system says the invoice total is ₹9,500A system of recordCounts
- The AI says the refund was approvedAttached by the AI itselfDoes not count
- An approval from long agoNot currentDoes not count
- Proof for a different orderAbout something elseDoes not count
What you get
Every answer comes with its reason.
A check is more than a yes or a no. You get three things back.
A reason you can act on
Each hold or ask names its cause in plain terms, like an old approval or proof for the wrong item. In the API it is a stable code, such as evidence_stale, so your team can see why and fix the proof.
A grant that expires
When the answer is go, qbrin returns a signed grant. It expires, and it is tied to the exact arguments you asked about. Your tool runs only with it.
A receipt for each decision
qbrin records what was asked, what it decided and why. It keeps a hash of the exact arguments, not a copy of your data, so a swapped request is easy to spot.
How it plugs in
One call, right before the side effect.
Wrap the tool, not the framework. Right before a tool does something real, your wrapper asks qbrin. It is one HTTP call, so it does not depend on your agent framework. We have tested it with LangGraph.
- 01The AI proposes
A tool call with its exact arguments.
- 02Your wrapper pauses it
Right before the side effect, in any framework.
- 03qbrin checks
Against current evidence from a system you trust, and your policy.
- 04Go, hold or ask
On go, qbrin returns an expiring grant tied to the exact arguments.
- 05A receipt is kept
The tool runs only on go. Every decision leaves a receipt.
Public sandbox
Try it with one request.
No key needed. The public sandbox runs in shadow mode: nothing is enforced, no real grant is issued, and receipts are temporary.
https://app.qbrin.com/v1/authorizePublic sandboxcurl -X POST https://app.qbrin.com/v1/authorize \
-H "Content-Type: application/json" \
-d '{
"action": "refund_payment",
"args": {
"paymentId": "PAY_123",
"amount": 48500,
"currency": "INR"
},
"evidence": [
{
"kind": "customer_request",
"value": "Customer refund request of INR 48500 for PAY_123 approved by Finance"
},
{
"kind": "refund_policy",
"value": "Policy 2026: full refunds allowed within 30 days"
}
]
}'What this exact request returns
- Answer
- Ask a person
decision: "escalate" - Reason
evidence_untrusted- May proceed
mayProceed: false- Mode
enforcementMode: "shadow"- Grant
grant: null
Why ask a person?
The request says a refund was approved, but the evidence is supplied by the caller, so qbrin treats it as untrusted (authority: "caller"). An action like refund_payment needs evidence attested by a system of record. That is what keeps an AI from vouching for its own action. Actions that need no evidence, like the browser_action example in the docs, are decided on access and policy alone.
See the full response, as captured from the sandbox
{
"decision": "escalate",
"reason": "evidence_untrusted",
"stage": "evidence",
"action": "refund_payment",
"blastRadius": "external",
"reversible": false,
"stages": [
{
"stage": "access",
"decision": "allow",
"reason": "ok"
},
{
"stage": "agent_policy_default",
"decision": "allow",
"reason": "policy allows write"
},
{
"stage": "evidence",
"decision": "hold",
"reason": "evidence_untrusted"
}
],
"proof": {
"claims": [
{
"claim": "refund_status(PAY_123)=approved",
"status": "untrusted_authority",
"authority": "caller",
"requiredAuthority": [
"stripe",
"billing",
"finance_erp",
"finance_approval",
"zendesk_finance",
"finance"
],
"trustLevel": "caller_unverified"
}
]
},
"bindings": [],
"evidence": {
"examined": 2,
"bound": 0,
"required": 2,
"ignored": 0
},
"grant": null,
"grantPreview": null,
"enforcementMode": "shadow",
"mayProceed": false,
"wouldBlock": true,
"receiptId": "qb_rec_2ddecc386bda4819",
"latencyMs": 2.5,
"publicSandbox": true
}The sandbox is for trying the answer. Grants and receipts that last, and enforcement, belong to a real workspace. See the API docs for the full request and response.
Proof
See it run on a real agent.
We ran a real LangGraph agent with and without qbrin on five scripted cases. Without a check, four unsafe actions ran. With qbrin, none did, and the valid one still ran. It is a scripted proof with simulated effects, not a customer result.
See a check on your own action.
Bring one action you would worry about an AI taking. In a 20-minute walkthrough we show qbrin checking it. Nothing changes in your tools.