Protocol Root
Execution-time authorization and admissible machine action.
Status: Public Working Draft
VEIP specifies (i) the minimum evidence fields required for an Authorization Evidence Pack (AEP), (ii) timing requirements relative to declared execution boundaries, (iii) integrity and custody requirements for AEP artifacts, and (iv) conformance procedures including deterministic replay. VEIP does not specify policy content, risk thresholds, or jurisdictional obligations.
Agentic systems increasingly trigger legally material actions (deny, route, execute, ledger writes) at machine speed. Governance programs anchored in documentation, committees, and post-hoc logs operate at audit speed. This creates a Supervisory Latency Gap. VEIP closes this gap by requiring admissible authorization evidence at the moment execution is attempted.
- Not a legal interpretation engine.
- Not a mandate for a specific policy language (OPA/Rego, Cedar, ABAC, etc.).
- Not an observability stack (monitoring is complementary, not sufficient).
- Not an identity provider; it consumes identity and key manifests.
1. Request → 2. Policy Version Resolved → 3. Constraint Evaluation → 4. AEP Generated + Signed
↓
5. Gate Decision: PASS | FAIL | ESCALATE ←——————————————————————————————————
↓
6. Commit Allowed or Halted ————————————————————————————————————————————————→ 7. Evidence Anchor (Hash Recorded)
↓
8. Export + Replay (Supervisory Audit) ←————————————————————————————————————
Normative: An AEP MUST be finalized prior to crossing the declared execution boundary. Post-commit evidence is forensic logging, not execution-time authorization.
VEIP is published as a Candidate Specification for institutional review. The stated objective is neutral stewardship under a public governance model once stabilized. This document contains normative language (MUST/SHOULD/MAY) and non-binding interpretive notes.
Applicability & Proportionality
Where VEIP applies, and what “good” looks like at different risk tiers.
VEIP applies to any machine-mediated workflow in which a discrete action produces externally observable, legally material, safety-relevant, or operationally irreversible effects at an execution boundary. Examples include: credit decisions, payments/ledger writes, access grants, configuration changes, data release, sanctions screening outcomes, and automated escalation routing.
- L1 conformance acceptable
- Batch export acceptable
- Replay optional (SHOULD for audits)
- L2 conformance expected
- Pre-commit gating at boundary
- Export within defined SLA
- L3 conformance required
- ESCALATE binding + custody
- Deterministic or bounded replay
- R1: AEP schema validity MUST be enforced for governed actions.
- R2: Pre-commit gating MUST be enforced at declared boundaries; evidence MUST be exportable.
- R3: Custody-bound escalation, integrity anchoring, and replay requirements MUST be satisfied for all governed transitions.
Oversight Ontology
Normative vocabulary and MUST/SHOULD requirements.
Execution Boundary
Logical point where a state transition becomes committed (e.g., DB commit, ledger write, denial issuance).
Normative: AEP MUST be finalized prior to crossing this boundary.
Authorization Evidence Pack (AEP)
Immutable, signed artifact bundle binding policy versioning, constraints evaluated, custody, stop-rights, and timestamps to an action.
Normative: AEP MUST be cryptographically unique per machine action.
Custody
Cryptographic record of human/system participation in authorization, escalation, and commit approval.
Normative: Custody references MUST point to verifiable public keys.
Constraint Set
Specific subset of policy rules evaluated for a given request (context-dependent).
Normative: Evaluated constraints MUST be referenced by hash in the AEP.
Stop-Right
Policy-bound mechanism that halts a transition at the boundary when constraints fail or custody is missing.
Normative: If stop-right triggers, transition MUST NOT commit.
Deterministic Replay
Reproduction of authorization results under identical inputs and policy artifacts.
Normative: Replay MUST reproduce identical results given identical inputs (or meet bounded replay criteria in Annex).
Formal State-Transition Integrity Model (STI)
Mathematical semantics for execution-time authorization.
A transition from Sᵢ to Sⱼ is Authorized iff: (1) Pₖ ∈ Registry_active, (2) γ(Sᵢ,Eₙ,Pₖ) ∈ {PASS, ESCALATE}, (3) an AEP is generated binding hash(Pₖ), hash(C_eval), custody, timestamp, (4) σ(AEP)=VALID, and (5) timestamp(AEP) ≤ commit_time.
δᵥ(Sᵢ,Eₙ) =
δ(Sᵢ,Eₙ) if (1–5) satisfied
Sᵢ otherwise (fail-closed)
Replay function R MUST satisfy: R(Sᵢ,Eₙ,Pₖ,C_eval) = γ(Sᵢ,Eₙ,Pₖ). Bit-exact equivalence is required when deterministic; otherwise bounded replay requirements apply (see Annex: AI Binding & Stochastic Replay).
Cryptographic Specification Profile
Minimum cryptographic requirements for integrity, authenticity, and non-repudiation.
- Hashing: SHA-256 or SHA-3-256 minimum; policy artifacts and evaluated constraint sets MUST be hashed.
- Signatures: System signatures MUST use ECDSA P-256 or Ed25519. Human custody signatures MUST be hardware-backed (HSM / Secure Enclave).
- Timestamp integrity: RFC 3161 TSA OR signed monotonic counter + trusted NTP/PTP. Institutions MUST document clock assumptions.
- Key management: Institutions MUST maintain key lifecycle registry, immediate revocation, and publish a public key manifest.
AEP MUST be serialized in canonical JSON or CBOR with deterministic field ordering. The schema MUST include a version identifier and MUST be compatible with conformance tests.
{
"aep_version": "1.0",
"aep_id": "AEP-2026-02-11-TX-9921",
"jurisdiction_id": "EU-DE",
"execution_boundary": "core_ledger_gateway_v2",
"policy_hash": "0x82f1...a21c",
"constraint_hash": "0xa1b2...9f10",
"evaluation_result": "ESCALATE",
"stop_right_triggered": true,
"timestamp_utc": "2026-02-11T14:21:03Z",
"custody_chain": ["SYS_KEY_01", "REVIEWER_ID_882"],
"signature": "0x9981..."
}
Protocol MUST allow algorithm rotation. Deprecation windows MUST be published; backward compatibility SHOULD be maintained for at least 24 months for non-breaking transitions.
Threat Model
Security assumptions and boundary protections.
- Unauthorized execution without certified policy binding.
- Silent escalation bypass (automation proceeds without custody).
- Forensic tampering (post-incident log manipulation).
- Policy drift (execution diverges from certified artifact version).
- Pre-commit gating at declared execution boundary.
- Policy hash + effective date binding via registry.
- Cryptographically verifiable custody chain for approvals.
- Evidence anchoring and replay constraints.
- Compromised endpoint inputs (“garbage in”).
- Malicious content within a properly certified policy.
- Fraud entirely outside digital boundaries.
- Root CA compromise (unless covered by institutional PKI controls).
- System clocks are synchronized (NTP/PTP) and auditable.
- Signing keys reside in HSM/Secure Enclave with revocation.
- Policy registry is immutable, highly available, and queryable.
Operational Resilience & Degradation Model
Fail-closed semantics, graceful degradation, and supervisory continuity.
- When AEP generation or verification fails, the system MUST default to BLOCK or ESCALATE based on declared risk tier.
- Evidence anchoring MUST be durable: partial writes MUST be detectable.
- Supervisory export MUST remain available under degraded modes (minimum “exam mode”).
Institutions MUST provide an “exam mode” allowing supervisors to retrieve AEPs, key manifests, policy registry snapshots, and replay transcripts for a defined review window. Exam mode MUST be accessible under incident conditions and MUST provide integrity proof for exported artifacts.
Incident Classification & Reporting Annex
Common taxonomy for VEIP-relevant incidents and reporting fields.
- Incident class (IC-#), severity, detection timestamp, and affected execution boundaries.
- Affected AEP identifiers and policy hashes (with jurisdiction IDs).
- Custody keys involved (public key IDs), revocation status at time of event.
- Containment action (block/escalate/rollback), and whether external parties were impacted.
- Export package hash for supervisory review (tamper-evident bundle).
Institutions SHOULD align notification timing with applicable jurisdictional incident regimes (e.g., operational resilience / ICT incident reporting). VEIP recommends: IC-1/IC-2 as “high priority” given direct authorization failure at execution boundaries.
Conformance Model
Claim boundaries and minimum capability tiers.
- Evidence emitted after commit boundary (forensic logging presented as authorization).
- Stop-right implemented as operational “kill switch” not policy-bound gate.
- Human approval recorded in workflow tools but not cryptographically linked to execution.
- Policy hash not bound to effective date and registry status.
Conformance Test Suite (CTS) v1.0
Normative tests, required markers, and reference vectors.
The CTS defines mandatory tests. Implementations claiming L1 MUST pass all A-series tests. L2 MUST pass A-series and B-series. L3 MUST pass A-through-E tests including custody, anchoring, and replay criteria.
A test vector MUST include: input context hash, policy hash, expected evaluation result, expected gate behavior, and expected replay output hash.
TV-001: context_hash: 0xaaa1... policy_hash: 0x82f1... constraint_hash:0xa1b2... expected_eval: PASS expected_gate: COMMIT_ALLOWED expected_replay_hash: 0x0f12... TV-002: context_hash: 0xbbc2... policy_hash: 0x82f1... expected_eval: FAIL[CONSTRAINT_DEBT_RATIO_EXCEEDED] expected_gate: COMMIT_BLOCKED expected_replay_hash: 0x9a88... TV-003: context_hash: 0xccd3... policy_hash: 0x82f1... expected_eval: ESCALATE[REASON_CONFIDENCE_THRESHOLD] expected_gate: COMMIT_BLOCKED_PENDING_CUSTODY expected_replay_hash: 0x55e0...
- Public key manifest (system + human) used for signatures.
- Policy registry snapshot or query transcript proving active status at execution time.
- Boundary mapping document linking declared execution boundary to code path.
- Replay transcript (inputs, policy hash, outputs) with output hash.
Registry Governance Model (Normative)
Certified policy artifacts, activation rules, revocation, and auditability.
The Registry is the authoritative source of certified policy artifact hashes and metadata for a jurisdiction or supervisory domain. Implementations MUST query the Registry (or an approved cached snapshot) to resolve policy version and active status prior to AEP finalization.
- Registry entries MUST include: policy_hash, effective date, status (ACTIVE/REVOKED/DEPRECATED), jurisdiction ID, and signing authority.
- Implementations MUST reject policies not marked ACTIVE at the AEP timestamp.
- Revocations MUST be publishable with immediate effect; implementations MUST respect revocation within defined maximum propagation delay.
- Registry MUST provide a machine-readable audit trail for changes (append-only or equivalent).
- Registry availability SHOULD be ≥ 99.9% for systemic domains; outages MUST trigger degradation states per resilience model.
VEIP does not prescribe who certifies policy content. The Registry enables separation of concerns: supervisors certify semantics; vendors compete on engines consuming certified artifacts.
Federated Registry Interoperability Profile
Multi-jurisdiction policy binding, trust anchors, and conflict handling.
Define the minimum interoperability behavior for federated registries so that cross-border institutions can bind multiple policy authorities to a single governed action without collapsing jurisdictional semantics.
- Each registry MUST publish a root public key and revocation list.
- AEP MUST include jurisdiction ID and registry root reference for each policy hash referenced.
- Supervisory nodes MUST verify membership: verify(policy_hash ∈ Registry_J).
AEP.policy_vector = [
{ "jurisdiction_id": "EU-DE", "registry_root_hash": "0x11..", "policy_hash": "0x82f1.." },
{ "jurisdiction_id": "SG-MAS", "registry_root_hash": "0x22..", "policy_hash": "0x93aa.." }
]
If policies across jurisdictions conflict for a single action, the implementation MUST trigger ESCALATE, record the conflict vector in the AEP, and require human custody resolution prior to commit.
Supervisory Verification Interface (SVI) Specification
Minimum API surfaces for examiners: retrieve, validate, replay, and export.
- Enable supervisors to retrieve AEP artifacts and proof chains without requiring proprietary internal system access.
- Support deterministic validation: schema validity, signature verification, registry membership, anchoring verification.
- Support replay (deterministic or bounded) with exportable transcripts.
The SVI MUST support exporting a tamper-evident bundle containing: AEP, policy registry proof, key manifest snapshot, anchor verification proof, replay transcript (if requested), and a package hash. The export MUST be suitable for supervisory recordkeeping.
- Retrieve AEP via GET /v1/aep/{aep_id}.
- Verify policy status via GET /v1/policy/{policy_hash} and confirm ACTIVE at AEP timestamp.
- Verify custody chain keys via GET /v1/keys/manifest; confirm no revocation at time-of-event.
- Confirm anchoring: compare AEP hash to evidence anchor record (D1 marker).
- Run replay via POST /v1/replay and validate output hash matches expected criteria.
AI Binding & Stochastic Replay Annex
How VEIP remains admissible when parts of the decision pipeline are stochastic.
VEIP does not require models to be deterministic. VEIP requires that authorization at the execution boundary be reproducible, inspectable, and bound to policy semantics. Where stochastic components exist upstream, the AEP MUST bind the admissible inputs/outputs that directly influence the authorization gate.
- Implementations MUST define a Replay Boundary: the minimal deterministic slice required to reproduce the authorization decision.
- AEP MUST include hashes of all artifacts crossing the replay boundary (prompts, retrieval results, feature vectors, tool outputs, rule evaluations as applicable).
- If deterministic replay is not feasible, bounded replay MUST reproduce (a) the same authorization outcome, and (b) the same constraint triggers, under the stored boundary artifacts.
The supervisory objective is not to recreate a model’s internal randomness, but to preserve an admissible chain from certified policy semantics to an enforceable execution decision. VEIP therefore treats AI outputs as inputs into authorization, and binds them as such.
Cross-Jurisdictional Alignment Matrix
How VEIP maps to common supervisory control intents (non-binding).
VEIP does not claim compliance with any framework. This matrix links VEIP mechanisms to typical control intents present across DORA, MAS, NIST, and OECD AI guidance. Jurisdictional semantics remain defined by authorities.
| VEIP Mechanism | DORA Intent | MAS Intent | NIST/OECD Intent |
|---|---|---|---|
| Pre-commit gating | ICT controls at critical functions; prevent unauthorized execution | Accountability in deployment; bounded autonomy | Govern/Manage: enforceable controls vs narrative |
| Policy hash + registry | Traceability; controlled change management | Transparency of rules governing decisions | Documented governance and versioning |
| Custody chain | Accountability; auditability of responsibility | Human accountability for outcomes | Assignment of responsibility and oversight |
| Deterministic/bounded replay | Audit evidence quality; reconstructability | Explainability via inspectable artifacts | Validation, monitoring, accountability evidence |
| Incident taxonomy | ICT incident management and reporting | Operational risk transparency | Risk management, controls effectiveness |
Migration Pathway for Legacy Institutions
Incremental adoption without “big bang” refactors.
VEIP adoption SHOULD begin at the highest-impact execution boundaries. Institutions can wrap existing authorization engines and workflows by (a) generating AEPs from existing decision logs and policy evaluations, and (b) progressively enforcing fail-closed gating.
- Phase 0 — Observe: Generate AEPs in shadow mode (no blocking). Validate schema + signatures (L1).
- Phase 1 — Gate One Boundary: Select a single critical boundary (e.g., ledger gateway). Enforce pre-commit gating (L2).
- Phase 2 — Custody + Escalation: Implement ESCALATE with cryptographic human custody for defined triggers (L3 subset).
- Phase 3 — Replay & Exam Mode: Implement deterministic/bounded replay and supervisor export package (L3 complete).
- Phase 4 — Federation: Bind multiple policy authorities and registry roots for cross-border operations.
- Instrumenting logging without gating (creates false sense of safety).
- Escalation without cryptographic custody (approval cannot be bound to execution).
- Policy versioning without registry active status (cannot prove admissibility).
Supervisory Pilot Program Template
How to run a bounded, regulator-safe VEIP pilot.
Demonstrate that execution-time authorization evidence can be generated, verified, and replayed for a defined high-impact use case without exposing proprietary models or internal business logic.
- Scope: one boundary, one use case, one policy authority, fixed timeline (e.g., 8–12 weeks).
- Outputs: AEP artifacts, registry entries, key manifest, anchoring proof, replay transcripts, export bundles.
- Sampling: supervisor reviews random sample + targeted incident samples (ESCALATE + FAIL outcomes).
- Success Criteria: pass CTS markers A1–E1 for pilot scope; demonstrate exam mode continuity.
- Pilot boundary map (code path ↔ execution boundary)
- Registry snapshot + certification metadata
- AEP corpus + export package hashes
- Replay report + discrepancy handling
- Incident drill: IC-1/IC-2 tabletop and evidence retrieval
Economic Impact Modeling Annex
A structured way to quantify impact without overstating claims.
VEIP impact is modeled through (1) reduced incident frequency/severity at execution boundaries, (2) reduced audit labor via deterministic evidence, and (3) reduced supervisory friction through standardized exports. Institutions SHOULD publish assumptions and avoid aggregate claims without evidence.
Institutions SHOULD publish results as: baseline → pilot → scaled deployment, with explicit confidence intervals and documented scope.
Public Consultation Draft (Jan 2027 Cycle)
Draft language to open institutional review without startup positioning.
The VEIP Editorial Board hereby opens public consultation for VEIP v1.0 Candidate Recommendation. Consultation period: 01 March 2026 – 01 January 2027. This consultation seeks technical and supervisory feedback on execution-time admissibility, registry governance, and replay criteria in agentic systems.
- Feasibility of deterministic vs bounded replay for stochastic systems.
- Registry federation trust anchors and cross-jurisdiction conflict handling.
- CTS realism and test vector completeness for high-impact boundaries.
- Proportionality thresholds for smaller institutions.
- Incident taxonomy thresholds and reporting practicality.
Comments MUST include: organizational affiliation, conflict-of-interest declaration, proposed revision text, rationale, and impact assessment. All comments are logged to the public archive.
Specification Governance
Neutrality safeguards, revision mechanics, and security disclosure.
To maintain execution-time neutrality, voting members MUST disclose material commercial affiliations. Editors with material conflicts on a proposal MUST recuse from final vote. Proposals MUST demonstrate interoperability with at least two disparate logic engines.
- All proposals submitted as VEIP-RFC with rationale, compatibility impact statement, and security considerations.
- Breaking schema changes MUST increment major version.
- Major revisions require minimum 90-day public comment period and updated CTS.
- Deprecated fields remain supported for a 24-month deprecation window unless security requires earlier removal.
“Issues affecting integrity, custody, anchoring, or replay MUST be disclosed under the Editorial Board’s responsible disclosure policy. Remediation guidance is published to the public archive.”
Formal Publications
Canonical artifacts and citable records.