Layer 1 — Context Graph
Property graph of the complaint → refund workflow. Nodes = entities (agents, tools, data). Edges = data/context flow with constraints.
Layer 2 — Data Tagging
Enterprise data classification register. Every field tagged with sensitivity level — defined once, applies to all workflows.
| # | Source | Field | Sensitive | Level | Rationale | Actions |
|---|
Layer 3 — Access Control
Per-agent access policies. Each agent has its own access card — expand to view and edit field-level permissions.
Layer 4 — Enforcement
L2 (sensitivity) + L3 (access) = enforcement decision. Five modes determine how each field is handled at runtime.
Enforcement Decision Matrix
Protected Workflow — Enforcement Applied
Same pipeline as Layer 1, now showing what each step actually receives after enforcement.
Layer 5 — Audit Trail
Cryptographic audit log. Every step recorded with hash chain — tamper-evident, regulator-queryable.
Audit Log
| # | Timestamp | Step | Agent | Action | Fields Received | L2 Tags | L3 Access | L4 Enforcement | What LLM Received | Entry Hash | Prev Hash |
|---|
Regulator Query Example
Claim: "RefundBot never saw the merchant's raw UPI ID"
Step 1: Locate audit entry #7 (RefundBot receives handoff payload)
Step 2: Check L3 column — RefundBot access to upi_id = "Verification"
Step 3: Check L4 column — Enforcement = "Compute-and-replace (boolean)"
Step 4: Check "What LLM Received" — upi_id field shows
is_valid_upi: true, not the raw valueStep 5: Verify hash chain integrity — each entry hash includes the previous hash
Verdict: Claim verified. RefundBot received a boolean, not the raw UPI ID.
Live Demo
Step through the workflow and watch all 4 governance layers enforce in real time at each step.
Step 0 / 14