AI actions require authorization

Protected workflow templates

One verify call, then branch on verdict.

Protected workflows help agencies sell higher-trust AI automations to larger clients.

Protected workflows make autonomous automations easier to approve, easier to explain, and easier to defend when clients ask what happened.

REVIEW_REQUIRED creates an operational pause before systems change.

Every verify call can log an execution receipt (receipt_id) for client reporting, QBRs, and disputes.

Deploy protected workflows for refunds, CRM updates, invoices, outbound AI, and support operations—verify once, then branch before Stripe, CRM, ERP, or email tools run.

Client-safe workflow

Verify before execute—humans approve risky paths, every run logs a receipt.

Protected by BiDigest

n8n refund workflow on Human approval branch with execution receipt before payout — Canvas paused on Human approval—payout blocked until a manager approves.

AI workflow
      ↓
BiDigest verify
      ↓
Continue · Human approval · Hard stop · Recompute (when indeterminate)
      ↓
CRM · Stripe · ERP

Reusable across every client

Protected refund template
        ↓
   ┌──────┴──────┐
Client A    Client B    Client C
(same verify · same review gates · execution receipts per run)

Reuse the same verify pattern across every client workflow your agency deploys.

Why agencies buy protected workflows

Operational trust you can deploy per client—not a governance workshop.

Agency problem	Protected workflow outcome
Client fears autonomous AI	Human review gates on risky paths
Harder procurement reviews	Execution receipts with receipt_id per run
Rebuilding logic every client	Reusable templates in your library
Delivery liability	Verify-before-execute on every binding action

Why enterprise clients ask for this

Without protected workflows:

AI decides
        ↓
Action executes
        ↓
Problem discovered later

With protected workflows:

AI proposes
        ↓
Verify
        ↓
Continue · Human approval · Hard stop · Recompute
        ↓
Action executes

What agencies unlock

The business shift when verify → verdict → branch is standard on every client deployment.

Before protected workflows	After protected workflows
Smaller SMB automations	Higher-trust enterprise workflows
Fear of autonomous actions	Human approval gates
One-off custom logic	Reusable protected templates
Hard procurement reviews	Operational control story
Weak post-incident evidence	Execution receipts per run

Four execution outcomes

Human review is not the same as infrastructure uncertainty. Shipped invoice templates branch four ways so failed verification cannot silently pass into manual approval queues.

Authorization must remain valid when work resumes—not only when it first starts.

Outcome	Meaning
Continue	Authorized to proceed
Human approval	Requires business judgment
Hard stop	Explicitly denied
Recompute	Authorization state indeterminate

REVIEW_REQUIRED — governance escalation; route to human judgment with receipt_id.
VALIDATION_UNAVAILABLE — authorization state indeterminate; fresh verify required (not a HITL queue).
Approvals can become stale. BiDigest requires fresh verification before resuming actions when authorization conditions may have changed.
Workflows do not automatically resume on old approvals when authorization conditions have changed.

n8n invoice workflow: Continue branch active after verify APPROVED with receipt_id and four-way switch — Continue — verify APPROVED, agency policy clear → proceed to payment / ERP.

n8n invoice workflow: default sample routes to Human approval branch with four-way switch and execution receipt — Human approval — verify APPROVED, agency policy escalates ($12k · new vendor).

n8n invoice workflow: lower amount and known vendor routes to Hard stop — verify denial without agency escalation — $500 · known vendor → Hard stop — live verify typically DENIED; map does not auto-approve.

n8n refund workflow: Recompute · Not HITL branch — indeterminate authorization, fresh verify required — Recompute · Not HITL — indeterminate state; fresh verify required (not a manager queue).

Compensation and reversal — fresh verify boundary

Rollback is not continuation of the forward receipt. Shipped refund templates block compensation until a new verify boundary completes — forward APPROVED receipts stay evidence only.

Run 1 — set operationType to compensation_reversal and compensationVerifyComplete to false: Map → Hard stop, recompute_required true, forward_receipt_authorizes_compensation false.
Run 2 — set compensationVerifyComplete to true (simulates fresh compensation verify): agency policy applies — amount 5000 → Human approval when verify APPROVED.
Production — replace the flag with a second BiDigest verify node for the reversal intent before payout.

n8n refund workflow canvas with COMPENSATION sticky — operationType compensation_reversal requires fresh verify boundary — Refund template — Case C sticky + four-way switch (owner capture).

n8n Map output: compensation_reversal without fresh verify — Hard stop, recompute_required true — Run 1 — no fresh compensation verify → Hard stop (verify may still show APPROVED).

n8n Map output: after compensationVerifyComplete true — Human approval for amount 5000 — Run 2 — fresh boundary satisfied → Human approval (continuation_permitted stays false until resume verify).

Protected workflow library

Downloadable n8n packs—import JSON, wire verify once, branch on verdict. Expand any row for the canvas capture and execution receipt.

Workflow	Purpose	Example review conditions
Protected Refund Agent	Pause large refunds	amount above threshold
Protected CRM Update Agent	Pause destructive CRM updates	owner · email · delete fields
Protected Invoice Approval Agent	Pause risky payments	high amount · new vendor
Protected Outbound AI Review Agent	Pause cold or bulk outbound	bulk send · cold template
Protected Support Escalation Agent	Pause credits and escalations	issue_credit · escalate

Protected Refund Agent
Pause high-value refunds before Stripe or CRM side effects.
REVIEW_REQUIRED
Workflow screenshot
Example review conditions
- amount > 500 (demo map node)
- Execution requires human review when authority changed
Download refund n8n JSON
Protected CRM Update Agent
Block or pause destructive CRM field writes.
REVIEW_REQUIRED
Workflow screenshot
Example review conditions
- owner, email, delete, lifecycle_stage, amount fields
Download CRM update n8n JSON
Protected Invoice Approval Agent
Pause payment on high amounts or new vendors before ERP runs.
REVIEW_REQUIRED
Workflow screenshot
Example review conditions
- amount > 2500
- vendorId contains new
Download invoice approval n8n JSON
Protected Outbound AI Review Agent
Pause bulk or cold outbound before email provider sends.
REVIEW_REQUIRED
Workflow screenshot
Example review conditions
- recipientCount > 25
- templateId includes cold
Download outbound review n8n JSON
Protected Support Escalation Agent
Pause credits and escalations before Zendesk or billing changes.
REVIEW_REQUIRED
Workflow screenshot
Example review conditions
- creditAmount > 100
- action: issue_credit, close_ticket, escalate
Download support escalation n8n JSON

Canvas branch logic (copy-paste pattern)

After verify, branch on verdict — invoice templates use four paths including indeterminate authorization (fresh verify, not HITL).

HTTP verify (POST /api/v1/admissibility/verify)
        ↓
   Map to agency verdict
        ↓
┌──────────────────────────────────────┐
│ IF verdict == APPROVED               │ → Continue workflow
│ IF verdict == REVIEW_REQUIRED        │ → Human approval queue + pause
│ IF verdict == REJECTED               │ → Hard stop + log receipt_id
│ IF verdict == VALIDATION_UNAVAILABLE │ → Recompute — fresh verify (not HITL)
└──────────────────────────────────────┘

Ready to deploy on a client account?

Partner intake — API key in minutes. Import a template, run verify once, branch on verdict.

Protect your first workflow

Technical implementation reference

HTTP wiring, curl, and raw verify response shapes. Open only when you are ready to implement.

n8n — HTTP Request node

Method	POST
URL	https://bidigest.com/api/v1/admissibility/verify
Authentication	Header — Authorization: Bearer {{$env.BIDIGEST_API_KEY}}
Body	JSON — same object as curl below

// n8n Code node — map verify response (pause · approve · continue)
const body = $json;
const reviewRequired = body.review_required === true;
let verdict = 'REJECTED';
if (reviewRequired) {
  verdict = 'REVIEW_REQUIRED';
} else if (body.admissibility_status === 'APPROVED') {
  verdict = 'APPROVED';
}
return {
  verdict,
  receipt_id: body.decision_receipt?.receipt_id ?? null,
};

Shipped templates set review_required in the Map node from your policy (amount, fields, cold sends). Low-level API field mapping is in the technical reference below—not on your canvas labels.

Make — HTTP module

Module: HTTP > Make a request
URL: https://bidigest.com/api/v1/admissibility/verify
Method: POST
Headers: Authorization: Bearer <api_key>, Content-Type: application/json
Body: Raw JSON — paste curl body below
Router on mapped verdict (APPROVED / REVIEW_REQUIRED / REJECTED)

curl (strict contract)

curl -sS -X POST "https://bidigest.com/api/v1/admissibility/verify" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "jurisdiction": { "regionCode": "us-fed", "industrySector": "financial" },
    "intent": {
      "agentId": "agency-agent:client-acme",
      "actionType": "refund_approval",
      "proposedPayload": { "action": "refund_approval", "amount": 500, "clientId": "client-acme" }
    },
    "sessionContext": {
      "sessionId": "session-acme-refund-001",
      "userId": "support_agent",
      "sessionStartTime": "2026-05-17T12:00:00.000Z"
    },
    "groundTruthBinding": {
      "domain": "agency-automation-demo.bidigest.com",
      "regulatoryId": "AGENCY_AUTOMATION_DEMO_V0"
    }
  }'

Verify response → agency verdict

The verify API returns admissibility_status and reason_code. Map once in your canvas to agency verdict vocabulary—branch on verdict, not on raw API strings alone.

API field (verify response)	Agency verdict	Workflow action
"admissibility_status": "APPROVED"	APPROVED	Continue the automation.
"admissibility_status": "DENIED"	REJECTED	Stop the workflow immediately.
review_required or policy pause signal (execution requires human review)	REVIEW_REQUIRED	Pause workflow and notify your team.

Enterprise dashboards may label core engine states ADMITTED or FAIL_CLOSED; agency workflows should standardize on APPROVED, REJECTED, and REVIEW_REQUIRED.

[PROPOSAL] Future agency-facing response wrapper: { "verdict": "APPROVED", "receipt_id": "rcpt_…", "internal_reason_code": "200_ADMITTED" }. Today: map from admissibility_status in your HTTP node.

Raw API response (today)

{
  "admissibility_status": "APPROVED",
  "reason_code": "200_ADMITTED",
  "decision_receipt": { "receipt_id": "rcpt_84721…" }
}

Use in your workflow (execution receipt)

{
  "verdict": "REVIEW_REQUIRED",
  "receipt_id": "rcpt_84721…"
}