🤖 AI

Verifiable Agentic Infrastructure: Proof-Derived Authorization for Sovereign AI Systems

This paper introduces the Distributed Trust Framework (DTF), a verification architecture that secures sovereign AI systems by replacing static identity-based authorization with a dynamic, consensus-driven model where execution authority is strictly derived from cryptographically verifiable Justification Proofs and an immutable Evidence Chain.

Original authors: Jun He, Deying Yu

Published 2026-05-18

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Jun He, Deying Yu

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are running a massive, high-security bank. In the old days, you gave your security guards (the AI agents) a master key that opened every door. You trusted them because they had the right ID badge. But here's the problem: these guards are now AI. They are fast, smart, but sometimes they get confused, hallucinate, or get tricked. They might try to open the vault door even when they don't need to, or they might try to move money they shouldn't touch, all while holding a perfectly valid ID badge.

The old system said, "If you have the badge, you can go." The new system, described in this paper, says, "Having the badge isn't enough. You need a specific, signed permission slip for exactly this one job, approved by a panel of judges, before you can move an inch."

This paper introduces a system called DTF (Distributed Trust Framework) to fix this. Here is how it works, broken down into simple parts:

1. The Problem: The "Standing Privilege" Trap

Currently, if an AI agent wants to delete a server or change a financial setting, it just uses its permanent login credentials. If those credentials are valid, the system says "Yes."

The Risk: An AI might make a mistake (like thinking a server is empty when it's actually running the company's website) and delete it. The system lets it happen because the AI had the "right" ID.

2. The Solution: The "Permission Slip" System

Instead of letting the AI act on its permanent ID, the DTF system forces a new process. Think of it like a high-stakes construction project:

Step 1: The Intent (The Blueprint)
The AI agent doesn't just "do" the action. It first submits a proposal: "I want to turn off Server X."
Step 2: The Justification Proof (The Safety Report)
Before anyone approves this, the system automatically generates a Justification Proof. This isn't a chat log of what the AI was thinking. It's a structured, machine-readable document that says:
- What are we doing? (Turn off Server X)
- Why is it safe? (Server X has no traffic, it's owned by Team B, and it's not part of a critical dependency).
- What are the limits? (Only this server, only for 5 minutes).
Step 3: The Consensus (The Panel of Judges)
This proof isn't approved by one person or one computer. It is sent to a Swarm of Evaluators. Imagine a panel of different experts:
- One checks the rules (Policy).
- One checks if the server is actually empty (State).
- One checks if it's too risky (Risk).
- One might be a human for big decisions.
  They all look at the same proof. If they all agree (or reach a specific consensus), the action is approved. If one says "Wait, that server is actually critical," the whole thing stops.
Step 4: The Execution Identity (The Temporary Pass)
Once the panel approves the proof, the system creates a temporary, one-time pass. This pass is strictly limited. It says, "You can turn off only Server X, and only for the next 5 minutes." It cannot touch anything else.
Step 5: The Evidence Chain (The Black Box)
Every single step—the proposal, the proof, the judges' votes, the temporary pass, and the final result—is recorded in an unchangeable, permanent ledger. If something goes wrong later, auditors can replay the whole story to see exactly why the decision was made.

3. Why This Matters

The paper claims this system changes the rules of trust:

Old Way: Trust the Agent (the person with the badge).
New Way: Trust the Process (the proof, the judges, and the record).

Even if the AI agent is confused or hacked, it can't cause damage because it can't get the "Permission Slip" without the panel's approval. And even if it gets the slip, it can only do the one specific thing listed on it.

4. The Results (What the Paper Found)

The authors tested this system in a simulated cloud environment with 10,000 actions.

Safety: It stopped 100% of the "unsafe" actions (like trying to delete a server that was actually in use). The old systems let about 14% of these dangerous mistakes slip through.
Containment: It reduced the "blast radius." Instead of an AI having access to 450 servers, it only got access to the one server it was approved to touch.
Speed: The whole process (checking the proof, getting the judges' votes, and issuing the pass) took about 58 milliseconds on average. That's fast enough that it doesn't slow down the business.
Auditability: They could replay 99.9% of the decisions perfectly just by looking at the records, whereas the old systems left huge gaps in the story.

Summary Metaphor

Imagine a bank vault.

Old System: The guard has a master key. If he says "I need to open the vault," he opens it. If he's having a bad day or gets tricked, the vault opens.
DTF System: The guard has to fill out a form. A team of three different managers reviews the form to make sure the vault needs to be opened and that it's safe. If they agree, a machine prints a single-use, laser-cut key that only fits that specific vault door for 5 minutes. The guard uses that key, and a camera records every second of the process. If the guard tries to use that key on a different door, the lock simply won't turn.

The paper argues that for AI agents running our critical systems (like banks, power grids, or cloud servers), we need to stop trusting the "guard" and start trusting the "process."

Technical Summary: Verifiable Agentic Infrastructure – Proof-Derived Authorization for Sovereign AI Systems

1. Problem Statement

Modern cloud and enterprise systems rely on identity-centric authorization models, assuming that callers with valid credentials are safe to execute commands. This assumption fails in the context of autonomous AI agents, which can generate actions that are syntactically valid but semantically unsafe. Granting agents broad, standing permissions creates significant operational risks, particularly in sovereign AI systems where agents interact with critical infrastructure, regulated data, and financial workflows.

While "intent-governed" substrates (such as OpenKedge) mitigate this by interposing on agent actions—requiring agents to submit proposals for evaluation rather than mutating state directly—they leave a critical gap: the authorization decision itself is often unauditable and represents a single point of failure. The core problem addressed is how to make the decision to authorize an intent verifiable, distributed, and replayable. Specifically, the paper asks: What is the stable object that evaluators approve? How is temporary authority derived from an approval record rather than a caller's standing role? And what must be persisted to reconstruct why execution authority existed?

2. Methodology: The Distributed Trust Framework (DTF)

The authors propose the Distributed Trust Framework (DTF), a verification layer designed for governed mutation substrates. DTF shifts the locus of trust from the principal (the agent) to the decision lifecycle. It enforces a compact authorization invariant: no high-stakes execution without a proof object, no derived authority without consensus, and no valid mutation detached from evidence.

The framework operates through four primary constructs:

2.1 Justification Proofs (JP)

Instead of natural language explanations or post-hoc audit logs, DTF utilizes structured, machine-inspectable artifacts called Justification Proofs. A JP encodes the admissibility basis of an action before authority is issued. It contains:

Mutation Specification ( $M_t$ ): The proposed action.
Bound State and Context ( $S_t$ ): The authorization-relevant context snapshot at decision time.
Policy Basis ( $\Pi_t$ ): The specific policies and constraints applied.
Risk Assessment ( $R_t$ ): Classification of risk and required approval strength.
Execution Boundary ( $B_t$ ): The maximum allowable scope (action, resource, time, and obligations) if approved.

2.2 Consensus Validation

DTF distributes trust over authorization by requiring independent evaluators to attest to the same Proof object.

Evaluator Swarm: A heterogeneous set of evaluators (e.g., policy, state, risk, simulation, and human-supervised) processes the same JP.
Attestations: Each evaluator emits a signed attestation ( $a_i$ ) indicating approval, rejection, or abstention, along with structured objections.
Consensus Rule ( $q$ ): A governance rule computes the final decision based on quorum thresholds, evaluator diversity, and veto rights. Authority is only granted if the consensus explicitly approves the proof.

2.3 Execution Identity (EI)

Upon consensus approval, the system derives an Execution Identity.

Ephemeral Authority: Unlike standing roles, an EI is a temporary, non-transferable token.
Scope Derivation: The EI's scope is strictly bounded by the proof-derived boundary ( $B_t$ ). The system enforces that the effective scope of the identity cannot exceed the proof's boundary.
Implementation: In cloud environments, EIs are implemented as short-lived credentials (e.g., AWS STS sessions) with restrictive session policies.

2.4 Evidence Chains (EC)

To ensure replayability, DTF maintains an append-only Evidence Chain for every mutation attempt.

Completeness: The chain records the entire lifecycle: Intent, Context, Policy, Justification Proof, Attestations, Governance Metadata, Decision, Execution Identity, Mutation Attempt, and Outcome.
Replayability: This structure allows auditors to reconstruct the authorization basis without needing to re-simulate the agent's internal reasoning.

3. System Invariants

The paper defines four core lifecycle invariants enforced by DTF:

Proof-bound Execution: No high-stakes mutation executes without a corresponding valid Justification Proof.
Consensus-gated Authority: No Execution Identity is issued unless the consensus rule explicitly approves the proof.
Non-escalation: The effective authority scope of an Execution Identity must be contained within the proof-derived boundary.
Evidence Completeness: Every intent proposal, regardless of outcome, maps to exactly one structurally complete Evidence Chain.

4. Implementation and Evaluation

The authors instantiated DTF over an OpenKedge-based governed mutation substrate and deployed it as a suite of microservices (approx. 4,500 lines of Go) on AWS.

Architecture: The system includes an Intent Gateway, Justification Engine, Evaluation Swarm (using stateless AWS Lambda functions), Execution Broker, and Evidence Store (using Amazon QLDB).
Workload: The evaluation tested 10,000 synthetic agent mutations across three scenarios: destructive resource termination, production configuration mutation, and emergency break-glass execution.
Baselines: The system was compared against (B1) standing IAM credentials with standard audit logs and (B2) a policy-only precheck.

Key Results

Safety: DTF achieved a 100% block or escalation rate for all 2,400 unsafe variants (including stale state, missing dependencies, and protected-resource targeting). In contrast, the policy-only baseline (B2) allowed 14% of unsafe mutations to pass through.
Authority Containment: DTF reduced the mean effective execution scope from 450 resources (standing credentials) to exactly 1 approved resource per request, representing a 99.7% reduction in authority exposure.
Auditability: The Evidence Chain achieved 100% completeness. Auditors could reconstruct the authorization lifecycle for 99.9% of events without manual log correlation, compared to 23.0% for standard audit logs.
Latency: The end-to-end decision latency averaged 58.3 ms (median 52.6 ms), with a 99th percentile of 171.3 ms. The authors note this overhead is acceptable for high-stakes operations dominated by substrate latency and human review times.

5. Significance and Claims

The paper claims that DTF provides a foundational infrastructure for making agentic execution governable, auditable, and bounded in sovereign AI deployments.

Shift in Trust: The primary contribution is shifting the object of authorization from a durable principal to a recorded decision lifecycle. The system does not need to trust the agent's internal reasoning; it only requires that execution authority be derived from explicit proof, independent approval, and bounded issuance.
Verifiability: By structuring authorization as a replayable lifecycle of artifacts (Proof, Consensus, Identity, Evidence), DTF addresses the "unauditable decision gap" inherent in traditional policy engines.
Modest Scope: The authors explicitly state that DTF does not synthesize correct policy, guarantee globally optimal decisions, or solve prompt injection within the agent itself. Its value is architectural: it ensures that high-stakes authority cannot be legitimately materialized without recorded proof, recorded approval, bounded issuance, and durable evidence. The results are validated within controlled, architecture-controlled scenarios with known mutation classes, not as unconstrained internet-scale benchmarks.

The paper concludes that by enforcing the invariant "no high-stakes execution without proof, no authority without consensus, and no valid mutation detached from evidence," DTF transforms authorization from an audit aspiration into an executable, verifiable lifecycle.