Technical Summary: Sovereign Assurance Boundary for Agentic Infrastructure

1. Problem Statement

The integration of Large Language Model (LLM) agents into operational workflows introduces a critical control-plane authorization gap. While agents can propose high-stakes mutations to production resources (e.g., scaling nodes, rotating credentials, modifying network security groups), existing security mechanisms are insufficient to govern these non-deterministic reasoning systems.

• Static vs. Dynamic: Traditional Identity and Access Management (IAM) and policy engines enforce static permissions or structural compliance but cannot determine if an autonomous proposal is semantically justified by live evidence.
• Post-Hoc Limitations: Audit logs and consensus protocols record actions or agree on state transitions only after execution or without evaluating the semantic safety of the transition.
• Risk Accumulation: Individually plausible agent actions can accumulate into systemic failures, including availability outages, data exposure, policy bypasses, and loss of forensic context.
• The Core Gap: There is no runtime admission boundary that converts an agent's proposal into execution authority only after it is bound to evidence, policy, and revocation state.

2. Methodology: The Sovereign Assurance Boundary (SAB)

The paper proposes the Sovereign Assurance Boundary (SAB), a certificate-bound runtime admission boundary that interposes between agent reasoning and infrastructure mutation. SAB operates on the principle that the institution retains local control over policy, evidence, and execution authority, treating the agent runtime as an untrusted proposer.

2.1 Architecture: Airlock–Broker Model

SAB separates the system into two distinct layers:

1. Untrusted Agent Runtime: Generates proposals but holds no standing credentials or direct execution privileges.
2. Trusted Sovereign Execution Broker: The only entity permitted to invoke infrastructure APIs. It executes mutations exclusively upon verifying a signed Sovereign Assurance Certificate ($\Omega$).

The admission pipeline consists of the following stages:

• Contract Compilation: Raw agent commands are normalized into a strongly-typed Execution Contract ($C$), defining targets, preconditions, postconditions, and rollbacks.
• Evidence Binding: An evidence collector assembles telemetry, logs, and tickets to compute a cryptographic digest $H(E)$ of the system state at decision time.
• Consequence Scoring: A scorer calculates a risk metric $R(C)$ based on blast radius, privilege expansion, data sensitivity, irreversibility, and uncertainty. This determines the Autonomy Level ($L(C)$) (ranging from L0 Advisory to L5 Prohibited).
• Certification Path Routing: Based on $L(C)$ and policy, the contract is routed through a specific path (e.g., PolicyOnly, LightweightQuorum, SQA, SQAPlusHuman).
  • Semantic Quorum Assurance (SQA): A mesh of external, untrusted validators provides signed attestations ($\Gamma_{SQA}$) regarding the semantic admissibility of the action.
  • Human Approval: For high-stakes actions, operators provide multi-signature approvals bound to the specific contract and evidence.
• Certificate Issuance: The Assurance Airlock (part of the Trusted Computing Base) verifies all path requirements and issues a signed Sovereign Assurance Certificate ($\Omega$).
  • $\Omega$ contains: $C$, $H(E)$, $R(C)$, $L(C)$, certification path, validator signatures, execution identity ($ID_{exec}$), validity window ($T_{valid}$), policy version ($P_{ver}$), and revocation epoch ($\rho_{rev}$).
• Broker Verification: Before execution, the Sovereign Broker verifies $\Omega$'s signature, checks the revocation epoch, validates the policy version, and performs a state drift check ($\Phi_{drift}$) to ensure the live state has not deviated from the bound evidence $E$.

2.2 Formal Invariants

SAB enforces five authority-boundary invariants:

1. Proposal-Execution Decoupling: No agent proposal triggers a mutation without airlock admission.
2. Certificate-Bound Execution: Execution occurs only if the broker verifies a valid $\Omega$ containing the specific contract $C$.
3. Evidence Binding: Approvals and attestations are cryptographically bound to $C$ and $H(E)$, preventing reuse across different contexts.
4. Monotone Path Selection: Contracts are admitted only if all requirements of their selected certification path are satisfied; lower-assurance paths cannot override higher-risk requirements.
5. Ephemeral Authority: Certificates are rejected if the revocation epoch is stale or the execution time falls outside the validity window.

3. Key Contributions

The paper makes four primary contributions:

1. Certificate-Bound Admission: It defines a runtime admission boundary that converts autonomous execution authority from an ambient permission into a revocable, evidence-bound artifact.
2. Airlock–Broker Architecture: It introduces the specific components (Contract $C$, Evidence Digest $H(E)$, Certificate $\Omega$, and Sovereign Broker) that separate proposal, admission, and execution.
3. Consequence-Aware Certification: It formalizes consequence scoring, autonomy levels, certification paths, and revocation mechanisms that support escalation, rejection, and suspension before execution.
4. Prototype and Feasibility Evaluation: It implements a Go prototype demonstrating the system's feasibility, including contract serialization, OPA/Rego policy checks, Ed25519 signing, and a PostgreSQL-backed ledger.

4. Results and Evaluation

The authors evaluated the prototype using 500 labeled execution contracts across 2,500 admission attempts in a local testbed.

• Latency:
  • Policy-only admission: ~1.84 ms (p50).
  • SQA admission (with validator mesh): ~185 ms (p50) / 380 ms (p95).
  • Broker verification: ~0.15 ms (p50).
  • Revocation propagation: ~12.4 ms (p95).
• Accuracy:
  • Routing accuracy (agreement with expert-labeled oracle): 96.8%.
  • Unsafe admission rate: 0.4%.
• Efficiency:
  • Human approval reduction: 68.2% compared to a human-only queue.
  • Certificate storage overhead: ~3.4 KB per action.
• Replayability: 100% of ledger entries were replayable with schema context.

The results indicate that the control-plane overhead is feasible on a single workstation, trading latency for assurance and replayability.

5. Significance and Claims

The paper claims that SAB addresses a specific authorization gap without replacing existing security layers.

• Operational Sovereignty: SAB defines sovereignty as the institution's retention of local control over policy evaluation, evidence retention, signing keys, and execution authority. External models are restricted to proposal generation and cannot bypass local certification.
• Composability: SAB is not a replacement for IAM, formal verification, consensus protocols, or human review. Instead, it composes these mechanisms into a system-level admission boundary. It treats delegated execution authority as a certificate-bound, evidence-bound, revocable, and replayable runtime artifact.
• Risk Mitigation: By decoupling proposal generation from execution and binding execution to fresh evidence and active policy, SAB prevents autonomous reasoning alone from mutating state, thereby mitigating risks of systemic failure, data leakage, and policy bypass.

The authors maintain a modest stance, acknowledging that SAB relies on the integrity of the Trusted Computing Base (TCB), the freshness of external evidence, and the calibration of validators. They note that the prototype results are workload-dependent and do not guarantee general performance, suggesting an incremental deployment strategy starting with high-consequence domains.