Runtime Assurance Loop
The Runtime Assurance Loop connects MCP tool authorization, Proof-of-Mandate evidence, Verifiable Intent traceability, runtime evidence ingestion, and the Trust Operations cockpit. It is designed to make autonomous-agent authorization auditable after the decision has been made, without changing the underlying mandate enforcement semantics.
At runtime, Mandaitor still decides ALLOW, DENY, or ESCALATE from the mandate, policy mapping, and tool-call context. Sprint 4 adds a structured evidence layer around that decision: the Core runtime trace records PoM, VI-L3, actor, mandate, action/resource, and advisory drift material; Ops validates those events fail-closed before publishing trust data; and the dashboard surfaces the resulting assurance state to operators.
Definition: Runtime Assurance is the post-decision evidence loop that proves a tool authorization was bound to an active mandate, a Proof-of-Mandate artifact, and a Verifiable Intent L3 trace while preserving drift as an advisory governance signal.
End-to-End Flow
| Stage | Component | Evidence Produced | Failure Semantics |
|---|---|---|---|
| Tool authorization | mandaitor-core MCP authorization handler | mcp-runtime-trace/v2 response material with event, actor, PoM, VI-L3, mandate, action/resource, and drift fields | Authorization remains mandate-driven; drift collection is fail-open and advisory. |
| Evidence export | mandaitor-core evidence-pack handler | Evidence-pack schema 1.2.0, export_manifest, recomputable section digests, RBAC requester attribution, and EVIDENCE_PACK_EXPORTED audit event | Evidence exports fail if the pack or export audit event cannot be produced. |
| Evidence ingestion | mandaitor-ops runtime evidence generator | 2026-W19-runtime-authorization.yaml and runtime snapshots in trust-data.json | Evidence validation is fail-closed when required trace fields are missing or malformed. |
| Trust publication | Public docs generated assets | /generated/trust-data.json, /generated/assurance-pack.md, and compliance report outputs | Trust publication should only use validated generated artifacts. |
| Operator review | mandaitor-dashboard Trust Operations cockpit | Runtime Assurance Cockpit v2 showing contract version, freshness, event count, latest event, drift posture, and obligation coverage | The cockpit falls back to documented sample data only when live trust data is unavailable. |
Runtime Trace Contract
Runtime authorization events are normalized to the mcp-runtime-trace/v2 contract. Each ingested event must carry enough material for downstream verification and compliance mapping.
| Field Group | Required Fields | Purpose |
|---|---|---|
| Event identity | event_id, tenant_id, session_id, tool_name, decision | Provides a stable authorization event reference for audit and replay. |
| Actor binding | agent_id, agent_did | Binds the tool call to the authenticated autonomous actor. |
| Mandate binding | mandate_id, mapped_action, mapped_resource | Shows which mandate scope justified the runtime authorization. |
| Proof binding | pom_bound, vui_digest, verification_event_id | Links the authorization to Proof-of-Mandate and VUI evidence. |
| VI trace | vi_layer_type | Marks the runtime authorization as an L3 transaction-level trace. |
| Drift material | drift_score, drift_detected, drift_threshold, drift_dimensions | Provides advisory semantic-governance context without changing the authorization decision. |
| Drift session binding | drift_session_id, drift_window_start, drift_window_end, drift_session_action_count, semantic_signals | Shows which sliding session window and semantic signal payload produced the advisory drift posture. |
| VI-L3 claim payload | vi_l3_claims.vct, vi_l3_claims.mandate_id, vi_l3_claims.verification_event_id, vi_l3_claims.decision, vi_l3_claims.l2_binding | Preserves the transaction-level Verifiable Intent claim material that downstream evidence validation can cross-check. |
| Compliance mapping | controls, claims, obligations | Connects the event to public trust claims and obligations. |
The Core response is intentionally conservative: missing drift state must not block a valid mandate authorization, while missing runtime-evidence fields must prevent Ops from publishing an incomplete trust snapshot. The four current drift dimensions are semantic_distance, sequence_deviation, frequency_anomaly, and scope_expansion; each is validated as a normalized score between 0 and 1 before publication.
Evidence Export Integrity
Core evidence-pack exports now include a manifest that binds the exported mandate snapshot, event chain, proof tokens, and manifest metadata to recomputable digests. This gives auditors a stable integrity envelope around the export itself, separate from the already chained audit events.
| Integrity field | Operational meaning |
|---|---|
export_manifest.export_id | Stable identifier for one evidence-pack export operation. |
export_manifest.generated_by | Normalized requester attribution derived from Core RBAC context, including tenant and role/permission material when present. |
export_manifest.coverage | Scope of the export, including tenant, mandate, schema version, event count, and optional event filter. |
export_manifest.digests | Recomputable digests for the mandate snapshot, event chain, proof tokens, and manifest hash. |
EVIDENCE_PACK_EXPORTED audit event | Append-only ledger proof that the export occurred, including export ID, manifest hash, case-log hash, event count, and schema version. |
The standalone evidence-pack verifier checks the export manifest in addition to chain integrity and proof-token digest coverage, which allows offline reviewers to detect tampering in the export envelope before relying on the evidence pack. Wave 4 also makes this verifier part of the Core pull-request path through a golden evidence-pack fixture, so the integrity contract is tested before evidence-export changes can merge.
Trust Data Projection
Ops publishes runtime authorization evidence into trust-data.json under runtime_authorization. The dashboard consumes that collection directly and derives the live assurance summary from the first current snapshot. Wave 4 adds a second publication surface, evidence_pack_exports, so the Trust Operations cockpit can show whether recent evidence-pack export manifests were verified, which schema version they used, which manifest digest was recomputed, and which export audit event anchors the handoff.
{
"runtime_authorization": [
{
"evidence_id": "2026-W19-runtime-authorization",
"source": "runtime-authorization",
"contract_version": "mcp-runtime-trace/v2",
"freshness_status": "current",
"event_count": 1,
"allowed_events": 1,
"drift_detected_events": 0,
"max_drift_score": 0.12,
"latest_verification_event_id": "evt_runtime_authorization_fixture",
"events": [
{
"event_id": "evt_runtime_authorization_fixture",
"tool_name": "generic.authorization.execute",
"decision": "ALLOW",
"mandate_id": "mdt_runtime_fixture",
"mapped_action": "authorization.execute",
"mapped_resource": "runtime:evidence/*",
"pom_bound": true,
"vi_layer_type": "L3A",
"drift_score": 0.12,
"drift_detected": false,
"drift_threshold": 0.7,
"verification_event_id": "evt_runtime_authorization_fixture",
"controls": ["OP-005", "AA-001", "AA-002"],
"claims": ["TC-020", "TC-036"],
"obligations": ["OBL-001", "OBL-020", "OBL-040"]
}
]
}
]
}
This projection intentionally keeps both aggregate metrics and the event ledger. Aggregate fields support cockpit badges and trust summaries, while event fields support operator drill-down and documentation completeness audits.
Evidence-pack export manifest projection follows the same principle but intentionally remains compact because the full evidence pack may be customer- or incident-specific. The published trust data carries the integrity envelope and operational status rather than the pack contents.
{
"evidence_pack_exports": [
{
"export_id": "exp_wave4_fixture",
"source": "evidence-pack-export",
"generated_at": "2026-05-20T09:28:00.000Z",
"schema_version": "1.2.0",
"manifest_version": "1.0",
"manifest_digest": "sha256:96bfe1e6b3d7d9bb9e0c03f31e16b66bdf65de6f7f2d7f63cc35b59d94fb8f66",
"event_count": 3,
"file_count": 1,
"verifier": "offline-evidence-pack-verifier",
"status": "verified",
"latest_event_id": "evt_evidence_pack_exported_wave4",
"artifact": "mandaitor-core/lambdas/test/fixtures/golden-evidence-pack.json"
}
]
}
| Projection Field | Review Purpose |
|---|---|
export_id | Identifies the exact evidence-pack export operation being reviewed. |
manifest_digest | Gives reviewers the recomputed manifest hash that should match the offline verifier result. |
schema_version and manifest_version | Show whether the export used the current evidence-pack contract and manifest format. |
event_count and file_count | Summarize the coverage of the exported evidence envelope without publishing sensitive pack contents. |
verifier and status | State which verifier evaluated the export and whether it passed, warned, failed, or is missing. |
latest_event_id | Links the visible manifest card back to the immutable EVIDENCE_PACK_EXPORTED audit event. |
Compliance Closure
Runtime Assurance closes the evidence loop for public trust claims that require proof that autonomous actions are authorized, traceable, and mapped to operational controls.
| Public Claim or Obligation | Runtime-Assurance Evidence |
|---|---|
TC-020 — mandate verification uses W3C Verifiable Credentials | Runtime events include Proof-of-Mandate binding. |
TC-036 — runtime authorization decisions are bound to PoM and VI-L3 trace evidence | Runtime events include pom_bound, vi_layer_type, and verification_event_id. |
TC-039 — evidence-pack export manifests are verified offline and surfaced in Trust Operations | Trust data includes evidence_pack_exports with manifest digest, verifier status, schema version, event count, and latest export audit event. |
OBL-001 — security questionnaire readiness | Trust data now exposes a reproducible runtime authorization example and evidence source. |
OBL-020 — API uptime commitment | Runtime evidence references operational controls and published freshness status. |
OBL-040 — SOC 2 Type I readiness preparation | Compliance mapping now links runtime authorization to access, evidence, operations, and incident-response controls. |
Sprint 4 also closes adjacent compliance-evidence gaps that are required for the published Trust Operations view to be coherent. These controls are generated into the public compliance report even when they are not part of the runtime event ledger itself.
| Control or Obligation | Sprint 4 Evidence Closure |
|---|---|
DP-006 / OBL-011 | Data-subject request routing is represented as privacy-evidence closure so DSAR handling is no longer left as an unmapped privacy obligation. |
DP-007 / OBL-012 | Subprocessor transparency is represented as a privacy/transparency evidence closure and mapped into generated compliance outputs. |
OP-008 / OBL-001, OBL-020, OBL-040 | Runtime authorization evidence ingestion normalizes Core MCP authorization responses, validates PoM, VI-L3 and drift material, and publishes freshness-aware trust data. |
OP-009 / OBL-031 | Beta feedback intake and SLA routing are documented as operational evidence for pilot transparency and feedback processing. |
Dashboard Review Procedure
Operators review Runtime Assurance from the tenant Trust Operations page. The cockpit should show the Runtime Authorization card, contract version mcp-runtime-trace/v2, the latest verification event ID, PoM-bound and VI-L3 indicators, drift posture, mapped controls, and the obligations covered by the latest snapshot. It should also show the Evidence-Pack Export Integrity section for the latest evidence_pack_exports entry, including verifier status, manifest digest, schema version, event count, and the export audit event anchor.
| Check | Expected Result |
|---|---|
| Trust data load | The page reads /generated/trust-data.json and shows freshness_status: current for runtime authorization plus at least one verified evidence_pack_exports entry when export evidence has been published. |
| Event ledger | The latest event ID, tool name, decision, mandate ID, mapped action, mapped resource, actor DID, and verification event ID are visible. |
| Assurance badges | PoM binding, VI-L3 traceability, contract version, freshness, and advisory drift posture are visible together. |
| Drift drill-down | The runtime source artifact retains drift dimensions, drift-session window metadata, session action count, and semantic-signal material for audit review even when the cockpit summarizes them. |
| Compliance coverage | Runtime-related obligations appear with their mapped controls instead of stale gap text. |
| Export integrity | The evidence-pack export card shows verifier status, manifest digest, schema/manifest versions, event count, and latest EVIDENCE_PACK_EXPORTED event ID. |
Testing Checklist
| Test Area | Command or Manual Path | Expected Result |
|---|---|---|
| Core MCP runtime trace | Run the MCP authorization handler tests in mandaitor-core/lambdas. | Authorization responses include runtime trace, PoM, VI-L3, and advisory drift fields. |
| Core evidence-pack export | Run vitest run test/evidence-pack.test.ts test/evidence-verifier.test.ts and pnpm --filter @mandaitor/lambdas verify:evidence-pack:golden in mandaitor-core/lambdas or through pull-request CI. | Evidence packs include schema 1.2.0, a valid export manifest, RBAC requester attribution, offline-verifier coverage, and an EVIDENCE_PACK_EXPORTED audit event. |
| Ops runtime ingestion | Run the runtime-evidence and trust-data generator tests in mandaitor-ops. | Core-compatible events normalize into validated runtime evidence and trust data, including drift dimensions, drift-session metadata, semantic signals, VI-L3 claim payloads, and evidence-pack export manifest insights. |
| Public generated artifacts | Sync mandaitor-ops/generated/* into mandaitor-public/static/generated/*. | Public trust data and compliance reports no longer show stale runtime-assurance gaps. |
| Dashboard cockpit | Run Trust Operations page tests in mandaitor-dashboard. | Runtime Assurance Cockpit v2 renders live trust-data snapshots, evidence-pack export manifest status, and deterministic fallback data. |
| Manual QA | Follow the MCP Runtime Authorization and Runtime Evidence Closure scenarios in the testing guide. | A reviewer can reproduce the complete Core → Ops → Public Docs → Dashboard evidence loop. |
Boundary Conditions
Runtime Assurance does not make drift an enforcement signal. Drift remains advisory and is intended for governance, review, and future escalation workflows. Runtime evidence validation is stricter than runtime authorization because public assurance artifacts must not be published unless all required event, actor, mandate, PoM, VI-L3, and drift fields are present.