arXiv CSopen access

Sovereign Assurance Boundary: Certificate-Bound Admission for Agentic Infrastructure

Sovereign Assurance Boundary: Certificate-Bound Admission for Agentic Infrastructure

arXiv:2606.11632v1 [cs.CR] 10 Jun 2026

Jun He OpenKedge.io

Deying Yu OpenKedge.io

Abstract

runtime admission boundary, individually plausible actions can accumulate into availability failures, data exposure, policy bypasses, or loss of forensic context. Sovereign Assurance Boundary (SAB) interposes between agentic reasoning and high-stakes infrastructure mutation. We use “sovereign” operationally: the institution retains local control over policy evaluation, evidence retention, signing keys, revocation state, broker identity, and execution authority. It is not an agent monitor or a general governance process; it defines a certificate-bound admission boundary where an agent proposal is not treated as ambient authority. Under SAB, a proposal is eligible for execution only after it is compiled into a typed execution contract C, bound to an evidence digest H(E) and policy version, assigned a consequence score R(C) and autonomy level L(C), routed through a consequence-aware certification path CertPath(C), encoded as a signed certificate Ω, checked against active revocation state, and verified by a sovereign execution broker immediately before mutating the target system. The mechanism converts autonomous execution authority from an ambient permission into a revocable, evidence-bound runtime artifact. SAB separates action-level and system-level assurance. Semantic Quorum Assurance (SQA) [3] serves as the actionlevel certification primitive. While SQA validates individual proposed actions, SAB composes SQA with evidence, policy, human approval, sovereign execution identity, revocation, and replay. SAB is independent of the SQA implementation: any validator mesh returning signed action-level attestations can instantiate ΓSQA . Action-level checks address unsafe individual mutations; system-level assurance binds execution to active policy, evidence, revocation state, and broker-enforcement paths.

Agentic infrastructure creates a control-plane authorization problem: non-deterministic reasoning systems may propose high-stakes mutations to production resources, but existing access controls (IAM), policy engines, consensus protocols, and audit logs either enforce static permissions or record actions only after execution. This paper introduces the Sovereign Assurance Boundary (SAB), a certificate-bound runtime admission boundary for autonomous execution authority in agentic infrastructure. SAB intercepts agent proposals at an assurance airlock, compiles them into typed execution contracts C, binds those contracts to cryptographic evidence digests H(E) and policy versions, and routes them through consequenceaware certification paths. Successful admission emits a signed Sovereign Assurance Certificate (Ω) that is valid only for a scoped execution identity, revocation epoch, and validity window. A sovereign execution broker verifies the certificate Ω and performs fresh pre-execution revocation and drift checks before invoking infrastructure APIs. We describe the airlock– broker architecture, formalize the admission and revocation invariants, and report preliminary feasibility measurements from a Go prototype over 2,500 admission attempts. The resulting model prevents autonomous reasoning alone from mutating state and turns delegated execution authority into a certificate-bound, evidence-bound, revocable, and replayable runtime artifact.

1

Introduction

Large language model (LLM) agents are increasingly connected to operational workflows rather than advisory interfaces, allowing them to scale resources, rotate credentials, deploy code, and export diagnostic data [1, 2]. In this setting, agentic infrastructure needs an admission mechanism that decides when a proposed action may become execution authority. Granting non-deterministic reasoning processes direct mutation rights over production control planes creates a safety and authorization risk: agents can become the proximate cause of physical or digital state transitions. Without a

Running Example. Consider an operations agent, Aops , tasked with resolving a service degradation. To restore reachability and diagnose the issue, Aops proposes reconfiguring network security groups, scaling up compute nodes, rotating database credentials, rolling back a deployment, and export1

4. Prototype and feasibility evaluation. We implement an initial Go prototype with contract serialization, OPA/Rego policy checks, Ed25519 certificate signing, a PostgreSQL-backed append-only ledger, revocationepoch distribution, broker verification, and replay tooling. Using 500 labeled execution contracts over 2,500 admission attempts, we report preliminary local feasibility measurements for admission latency, broker verification, revocation propagation, routing accuracy, replay completeness, and certificate overhead.

ing diagnostic logs. If an infrastructure stack lets that proposal directly invoke raw IAM permissions, autonomous execution of the sequence introduces systemic risk: the network change may expose private services, the resource expansion may exceed budget or quota constraints, credential rotation may trigger auth failures, the rollback may reintroduce vulnerabilities, and the log export may leak personally identifiable information (PII). The example shows why action-level checks alone do not bound institutional risk. What SAB Is Not. SAB differs from existing controls in several ways: • Not an IAM replacement: IAM authorizes identities and requests; SAB certifies whether an autonomous proposal is semantically justified by evidence before a broker invokes those credentials. • Not a formal verification replacement: SAB does not prove arbitrary safety, but composes formal proofs (when available) as inputs to its evidence digests. • Not a consensus protocol: Consensus (e.g., Raft) agrees on state transitions; SAB evaluates whether a transition is institutionally authorized under current context. • Not only logging: Logs record events post-execution; SAB binds pre-execution evidence and policy versions in the certificate Ω, then links outcomes through a ledgerrecorded outcome record O, making the admission process replayable. • Not only human-in-the-loop approval: SAB is a system-level runtime admission boundary that cryptographically binds human signatures to specific contracts and evidence snapshots, preventing generic rubberstamping. We make four contributions: 1. Certificate-bound admission for autonomous infrastructure. We identify a control-plane authorization gap that arises when non-deterministic agents are allowed to propose production mutations, and define the Sovereign Assurance Boundary (SAB) as a runtime admission boundary that converts agent proposals into certificatebound execution authority. 2. A concrete airlock–broker architecture. We introduce the assurance airlock, typed execution contract C, evidence digest H(E), the certificate Ω, and sovereign execution broker. Together, these mechanisms separate proposal, admission, and execution so that agent reasoning alone cannot directly mutate infrastructure state under the broker-enforced execution model. 3. Consequence-aware certification and revocation. We formalize consequence scoring R(C), autonomy levels L(C), certification paths CertPath(C), monotone path selection, broker-side verification, and revocation epochs ρrev . These mechanisms support escalation, rejection, suspension, and revocation before execution.

2

Background, Motivation, and System Requirements

2.1

Background and Gap

Securing agentic infrastructure requires integrating modelgenerated proposals with existing safety and security mechanisms. Runtime Assurance. Traditional runtime assurance separates an advanced controller from a monitor or fallback controller to prevent safety envelope violations [4,5]. In cloud and database administration, mutations are discrete, policy-laden configuration changes. SAB adapts the runtime-assurance pattern by evaluating the institutional admissibility of proposals rather than continuous physical invariants. Assurance Cases. Assurance cases present structured safety, security, or compliance arguments by linking claims to evidence [6]. They are usually static, design-time artifacts. SAB moves part of that structure into runtime admission by cryptographically binding telemetry, policies, and validator signatures to SAB certificates. Access Control (IAM) and Policy Engines. Zero trust and identity management systems (IAM) verify caller identities and enforce structural policy compliance (e.g., via OPA Rego) [7–9]. While IAM dictates whether an identity can call an API, it cannot determine whether an autonomous proposal is semantically justified by live evidence. SAB treats access control as a prerequisite, interposing a semantic certification boundary before credentials are used. Consensus and Byzantine Fault Tolerance. Consensus protocols (e.g., Paxos, Raft, PBFT) replicate logs and enforce order across replicas [10,11]. They ensure agreement on state transitions but do not evaluate the semantic correctness or safety of those transitions. Semantic Quorum Assurance (SQA) certifies the semantic admissibility of individual proposed actions [3]; SAB composes SQA into a system-level certification boundary. 2

3

AI Safety and Tool Governance. Agent safety tools (sandboxing, output filtering, model self-critiques) constrain agent execution environments [1, 12]. These mechanisms lack cryptographically signed, institutionally bound execution credentials or durable audit trails. SAB wraps these tools as untrusted validators and binds their collective output into SAB certificates. 2.2

The Sovereign Assurance Boundary (SAB) intercepts agent proposals before they can mutate production infrastructure. The system model separates unprivileged agent reasoning from privileged sovereign execution. 3.1

System Model and Assumptions

We model the agent runtime as an untrusted proposer. It may be compromised, misaligned, or faulty, and has no standing administrative credentials. Downstream infrastructure APIs accept state mutations exclusively from the sovereign execution broker. The trusted computing base (TCB) consists of the assurance airlock, policy engine, evidence ledger, revocation controller, private signing keys, and sovereign execution broker. The contract compiler, evidence collector, consequence scorer, SQA validator mesh, and approval console run outside the TCB but are security-relevant; Table 2 maps each component to its trust boundary and core systems function. The evidence collector is untrusted: while SAB detects unsigned or malformed evidence, signed false evidence from compromised authorized sources remains a residual risk. Similarly, the SQA mesh is an external, untrusted oracle: the airlock policy engine verifies validators’ signed attestations ΓSQA instead of trusting validator internal execution. SAB assumes authenticated component identities, a versioned policy store, bounded clock skew, append-only ledger integrity, and timely propagation of revocation state. Let pkSAB denote the airlock’s public verification key and σSAB its signature on the certificate Ω.

Motivation: Why Action Certification Is Not Enough

Semantic Quorum Assurance (SQA) verifies locally whether an action is semantically admissible (e.g., whether a securitygroup change fits an active outage ticket). High-stakes infrastructure also needs a system-level check: whether the agent operates under active policies, fresh evidence, and current revocation rules. A sequence of individually approved steps (e.g., opening a firewall, expanding an IAM role, rolling back a service, and exporting logs) can collectively create high-consequence availability, compliance, or security failures. Table 1 summarizes how SAB composes these security controls. SAB mediates the certificate-bound transition from proposal to execution, checking that the certificate Ω contains the evidence and validation epoch required by policy. 2.3

SAB Architecture and Trust Model

System Requirements

To govern high-stakes agentic infrastructure, SAB must satisfy seven system requirements: R1: Proposal/Execution Separation. Agent runtimes must have no standing credentials or direct execution privileges, treating them purely as action proposers.

3.2

R2: Contractual Admission. Raw agent commands must compile into a strongly-typed execution contract C defining target resources, preconditions, postconditions, and rollbacks.

SAB Invariant Properties

Under the trust model in Section 3.1, SAB enforces five authority-boundary invariants: P1: Proposal-Execution Decoupling Invariant. Let Mutate(r, op) denote a state-changing operation on resource r. Under the assumption that the infrastructure API accepts mutations only from the sovereign broker, no agent proposal can directly trigger Mutate(r, op) without first being admitted by the airlock:

R3: Evidence-Bound Decisions. All admissions must bind to a cryptographic digest H(E) of the telemetry and system state active at decision time. R4: Consequence-Aware Routing. Proposals must route to validation paths dynamically based on a consequence score R(C) (blast radius, irreversibility, data risk, and uncertainty).

Execute(Ω) =⇒ Admit(C) where C is the compiled execution contract corresponding to the proposal. P2: Certificate-Bound Execution Invariant. The sovereign execution broker executes a contract C only after verifying the certificate Ω and its airlock signature:

R5: Sovereign Execution. Admitted contracts must execute exclusively through an institutionally controlled broker that scopes credentials and validates the certificate Ω. R6: Revocability. The system must support scoped withdrawal, enabling key rotation, validator quarantine, and domain suspension.

Execute(Ω) =⇒ Verify(pkSAB , Ω, σSAB ) ∧ C ∈ Ω

R7: Replayability. SAB must record the certificate Ω and, after execution, outcome record O in an append-only log, with the ledger binding O to Ω.

where the certificate is bound to the specific contract C, policy version Pver , execution identity IDexec , and validity window Tvalid . 3

Table 1: Admission controls for agentic infrastructure. SAB certifies the institutional admission context surrounding individual actions. Control

Question

Artifact

Failure if Missing

Policy engine SQA Human approval Audit logging SAB

Is the caller authorized for this operation? Is the proposed action semantically admissible? Does an operator approve this step? What happened after execution? May this proposal become execution authority under institutional rules?

Authorization token Action certificate Approval record Event log SAB certificate Ω

Static permissions are treated as ambient authority. Locally unsafe mutations are executed. Approvals do not bind evidence or policy epochs. Accountability is reconstructed post-hoc. Individually safe actions cross into execution authority without system context.

LEGEND: SAB Trusted TCB (Contribution)

Policy engine

SAB Security-Relevant (Contribution)

SQA validator mesh

Approval console

External / Baseline Systems

Agent runtime

proposal

Contract compiler

C

Evidence collector

H(E)

Consequence scorer

Replay/audit service

R, L

Assurance airlock

Evidence ledger

Ω

Sovereign broker

scoped mutation

Infrastructure

Revocation controller

Figure 1: Reference architecture for the Sovereign Assurance Boundary. P3: Evidence-Binding Invariant. Approvals and validator attestations (ΓSQA , Γhuman ) are bound cryptographically to C and the evidence digest H(E):

Assumptions. 1. Infrastructure APIs accept mutations exclusively from the sovereign execution broker. 2. The broker verifies certificate signatures using the airlock public verification key pkSAB and rejects invalid signatures. 3. Airlock private key remains uncompromised. 4. Active policy Pver dictates path requirements.

Approve(C, H(E)) =⇒ Sign(Γ, C ∥ H(E)) This binding prevents approval reuse across different contracts or stale environmental contexts. P4: Monotone Path Invariant. A contract C is admitted only if all validation steps required by its selected certification path CertPath(C) are satisfied:

Argument. To execute a mutation, the broker must verify the certificate Ω such that C ∈ Ω and Verify(pkSAB , Ω, σSAB ) (by P2). Because the airlock private key is secure, only the airlock could have produced σSAB . The airlock emits this signature only if Admit(C) evaluates to true. By P4, Admit(C) evaluates to true only if all path requirements VerifyPath(C, CertPath(C)) are satisfied under the policy Pver . Under the assumptions above, an agent proposal cannot execute unless it compiles to a contract C satisfying the path checks mandated by institutional policy. Broker-enforced execution leaves agent reasoning with no direct mutation path (P1).

Admit(C) =⇒ VerifyPath(C, CertPath(C)) where CertPath(C) depends on the consequence score R(C), autonomy level L(C), and policy version Pver . Policy may escalate a contract to stronger assurance or rejection, but lower-assurance paths cannot override requirements imposed by action class, consequence score, jurisdiction, or incident mode. P5: Ephemeral Authority Invariant. The sovereign execution broker rejects any certificate Ω if the current revocation epoch ρactive is greater than the certificate’s revocation epoch ρrev , or if the execution time texec falls outside the validity window Tvalid :

3.4

Before invoking infrastructure APIs, the sovereign broker evaluates the pre-execution checks in Table 3. The checks cover certificate validity, contract identity, revocation state, policy epoch, state drift, and scoped credential issuance.

Execute(Ω) =⇒ ρrev = ρactive ∧ texec ∈ Tvalid The broker therefore rejects certificates from stale epochs. 3.3

Broker Verification Checks

3.5

Proof Sketch

Worked Admission Example

Consider an operations agent Aops proposing an ingress network rule Cfw to resolve an outage. Table 4 traces this proposal through the reference architecture. The example has two failure cases:

Goal. Establish that an untrusted agent runtime cannot directly execute a state-changing operation except through a broker-verified certificate satisfying the active policy path. 4

Table 2: SAB Component Reference. Component

Trust Boundary

Core Systems Function

Agent Runtime Contract Compiler Evidence Collector Consequence Scorer Policy Engine Assurance Airlock SQA Validator Mesh Approval Console Sovereign Broker Evidence Ledger

Untrusted / Outer Security-relevant / Airlock Security-relevant / Airlock Security-relevant / Airlock Trusted Control Plane Trusted Control Plane Fallible / Outer Mesh Security-relevant / Outer Trusted Control Plane Trusted Control Plane

Revocation Controller Replay Service

Trusted Control Plane Security-relevant / Outer

Proposes mutations as unprivileged JSON requests. Normalizes natural-language or tool calls into structured contracts C. Assembles telemetry, dependency logs, and tickets to compute evidence digest H(E). Estimates blast radius and data risk; determines autonomy levels L(C). Enforces static rules and routes remaining ones to certification paths. Enforces path predicates, collects approvals, and issues signed SAB certificates Ω. Evaluates action semantics as decoupled, untrusted signing oracles. Presents structured contracts and evidence summaries for operator multi-signature. Verifies signatures and revocation status of Ω; executes scoped actions through IAM. Durably records SAB certificates and bound outcome records O in an append-only cryptographic log. Monitors system state; advances revocation epochs ρrev and manages suspensions. Re-evaluates ledger records to reconstruct and audit historical admission decisions.

Table 3: Broker verification checks. Broker Check

Input

Failure Behavior

Signature tion

Certificate Ω, public key pkSAB , signature σSAB Contract C, certificate contents C ∈ Ω Current time texec , validity range Tvalid Certificate epoch ρrev , active epoch ρactive Certificate policy version Pver , active Pactive Bound evidence E, live state Stexec , threshold Scoped identity IDexec , target resource API

Reject execution, abort

Verifica-

Contract Match Validity Window Revocation Epoch Policy Epoch

State Drift Check Credential Issuance

artifact. The airlock implements the admission function: Airlock(C, E, St ) → Ω or Reject. The function returns Ω only when the proposal satisfies the required certification path. Otherwise, it returns Reject. To prevent time-of-check to time-of-use (TOCTOU) risks, the broker evaluates a state drift-check predicate Φdrift (E, Stexec ) immediately before executing the mutation, verifying that the live state at execution time Stexec has not deviated from the bound evidence E beyond policy safety margins.

Reject execution, abort Reject execution, abort Reject, fail-closed for L3 /L4 Reject execution, abort

Reject, fail-closed for L3 /L4

4.2

The consequence score R(C) quantifies the operational, compliance, and security risk of the contract:

• Airlock policy rejection: If Aops attempts to open port 22 (SSH) to the public internet (0.0.0.0/0), the consequence scorer maps this high-risk action to L4 . The airlock’s security-archetype validator detects a policy violation and triggers a critical veto, returning Reject.

R(C) = αB(C)+βP (C)+γD(C)+δI(C)+ηU (C). (1) The terms measure specific risk vectors: • Blast radius B(C): Affected resources, services, and network zones. • Privilege expansion P (C): Elevated credentials or access scopes required. • Data sensitivity D(C): Exposure risk of regulated data or PII. • Irreversibility I(C): Computational cost and difficulty of rolling back. • Uncertainty U (C): Lack of telemetry or confidence in evidence. To tune the weights (α, β, γ, δ, η), security engineers run an offline adjudication loop replaying historical incidents to tune classifications against expert consensus, biasing weights to escalate rather than under-classify when uncertainty U (C) is high. From the consequence score, active policy Pinst , and jurisdictional constraints J , the airlock maps the contract to an autonomy level:

• Broker-side verification failure: If Cfw is admitted at time t1 , but before execution at t2 the active revocation epoch advances from ρ1 to ρ2 , the broker detects that ρrev = ρ1 < ρ2 and aborts the execution. Similarly, if the broker’s drift-check predicate Φdrift (Efw , St2 ) evaluates to false (indicating that the target security group’s state has drifted since admission), the execution is aborted.

4

Certificate-Bound Admission Pipeline

The admission pipeline evaluates proposals, scores consequence, routes them to certification paths, and issues signed certificates that the broker can verify before execution. 4.1

Consequence Scoring and Autonomy Levels

Reject execution, abort

Formal Admission Interface

Let C be an execution contract, E be the evidence bound to that contract, St be the observed infrastructure state at time t, R(C) be the consequence score, and L(C) be the assigned autonomy level; the certificate Ω is the resulting admission

L(C) = Λ(R(C), Pinst , J ). Table 5 defines the consequence-aware autonomy levels. 5

Table 4: Worked example stages for security-group admission. Stage

Component

Output / Artifact

Example Value

Failure Check

1. Compile

Contract Compiler

Execution Contract Cfw

2. Bind Evidence 3. Score Consequence 4. Route Path 5. Airlock Check 6. Exec Check

Evidence Collector

Evidence Chain Digest H(Efw )

Consequence Scorer

Consequence Score

Malformed syntax, unsupported API Stale telemetry, missing incident ticket Score calculation failure

Policy Engine Assurance Airlock

Certification Path SAB certificate Ωfw

Sovereign Broker

Broker execution decision

Evidence Ledger

Ledger transaction

Add ingress rule; target: sg-01; port: 443; rollback: delete rule Telemetry (high latency); target config; incident ticket ID: INC-101 R(Cfw ) = 8.5; autonomy level L(Cfw ) = L4 CertPath(Cfw ) = SQAPlusHuman Signed bundle including Cfw , H(Efw ), ΓSQA , Γhuman Verify σSAB with pkSAB , check Φdrift (Efw , Stexec ), verify ρrev Record Ofw bound to Ωfw

7. Record Log

Monotone path mismatch Validator veto, missing human signature Drift limit exceeded, stale epoch Ledger write failure

Table 5: Consequence-aware autonomy levels. Level

Class

Example Action

Assurance and Validation Obligation

L0 L1 L2 L3 L4 L5

Advisory Manual Draft Bounded Autonomous Governed Autonomous High-Stakes Autonomous Prohibited

Diagnostic query Batch restarts Stateless restart Autoscaling or rollback Security group, log export Deleting audit logs

Read-only; agent cannot compile or execute. Agent drafts contract; manual operator submission required. Reversible, local action; OPA policy checks. Moderate blast radius; requires SQA and evidence binding. High blast radius; SQA, human multi-sig, revocation checks. Categorically denied autonomous execution.

4.3

Certification Paths

4.4

After assigning L(C), the airlock routes the contract through a certification path:   Reject, PolicyOnly,  CertPath(C) → LightweightQuorum, SQA, . (2)   SQAPlusHuman, Prohibited

Admission Predicate

To admit a contract, the airlock evaluates the admission predicate: Admit(C) = Φpolicy (C) ∧ Φevidence (C, E) ∧ Φassurance (C) ∧ Φauthority (C).

(3)

• Φpolicy (C): Policy permits the action class and target resource. • Φevidence (C, E): Required evidence exists, is fresh, and has trusted provenance. • Φassurance (C): The selected assurance path completed successfully. • Φauthority (C): The broker identity, validity window, and revocation state are valid.

The selected path determines the validation requirements: • PolicyOnly: Requires a valid contract, evidence digest, and a successful policy engine (e.g. OPA) check. • LightweightQuorum: Requires multiple automated validator checks (syntax checks, telemetry checks, and dependency checks). • SQA: Requires Semantic Quorum Assurance and validator diversity constraints. • SQAPlusHuman: Requires SQA, critical-archetype veto checks, and operator multi-signature. • Prohibited / Reject: Categorically disallowed or failed admission attempts.

4.5

SAB Certificates

When the admission predicate is satisfied, the airlock issues the certificate Ω: Ω = ⟨C, H(E), R(C), L(C),

Decoupled SQA Oracle. To keep the SQA validator mesh outside SAB’s trusted computing base, validator nodes run as external, isolated processes. They receive a read-only input bundle containing C and E, and hold no credentials. Each validator i independently evaluates the proposal and generates a cryptographically signed attestation:

CertPath(C), ΓSQA , Γhuman , IDexec , Tvalid ,

(4)

Pver , ρrev , σSAB ⟩. where IDexec is the execution identity, Tvalid is the validity window, Pver is the policy version, ρrev is the revocation epoch, and σSAB is the airlock signature. After execution, the broker emits a separate outcome record:

Γi = Sign(keyi , C ∥ H(E) ∥ votei ∥ metadatai ). The airlock verifies validator signatures and checks diversity, quorum size, and veto requirements over the aggregated attestations ΓSQA = {Γ1 , Γ2 , . . . }. Even under compromise, individual validators cannot forge approvals without private keys, nor can they directly mutate infrastructure.

O = ⟨Ω, status, texec , H(Spost ), result, σbroker ⟩, (5) where σbroker is the broker signature. The ledger stores O and binds it to Ω. 6

Properties. • Replayability: The replay service reconstructs the decision using C, H(E), R(C), L(C), CertPath(C), Pver , and ρrev . • Non-repudiation: Approvals are cryptographically bound to C and H(E), preventing reuse or extraction. • Temporal Validity: The certificate expires when the validity window Tvalid closes or evidence freshness drops. • Outcome Binding: Post-execution observations are bound to Ω through outcome record O, not embedded in the original certificate. Table 6 compares SAB certificates with standard changeauditing artifacts.

5.3

5

6

During an incident, the controller identifies the affected domain d, installs a suspension or downgrade rule, and forces new proposals to human-only escalation. The broker invalidates pending certificates in d, while the replay service sweeps recent executions to link outcomes back to context. Emergency overrides that bypass SAB remove the evidence and identity constraints required for accountability. Emergency operations should instead pass through SAB under stricter constraints: narrow scopes, short-lived certificates, and mandatory post-hoc replay. If an override is abused, the controller revokes pending certificates, quarantines keys, and replays the executions under standard policy.

Revocation, Suspension, and Incident Response

6.1

Revocation Triggers and Withdrawal Mechanisms

Failure Prevented and Artifact. This path is intended to stop a latency diagnosis from becoming an overbroad network exposure or an unevidenced API call. The ledger records the contract, evidence digest H(E), validator signatures, and broker decision, allowing post-hoc verification that the change was semantically justified.

Formal Semantics

Let d be a domain or action class. Suspension is a futureadmission invariant: Suspended(d) =⇒ ∀C ∈ d, Admit(C) = False.

6.2

Case Study 2: Generated-Code Deployment

Scenario and Path. A software engineering agent generates a bug patch and proposes deploying it to a Kubernetes cluster. The proposal is compiled into contract C, which includes source diffs, target service, and rollback plans. The collector binds C to build provenance, test results, and vulnerability scans. The scorer distinguishes low-risk canary rollouts (routed to SQA) from privileged code changes or database migrations (escalated to SQAP LUS H UMAN). The airlock evaluates PDD (Protocol-Driven Development) invariants, verifying that the generated patch matches interface

(6)

The invariant is evaluated before path selection, preventing suspended domains from being bypassed. Certificate revocation is an execution invariant: Revoked(Ω) =⇒ Execute(Ω) = False.

Case Study 1: Enterprise Cloud Operations

Scenario and Path. An operations agent Aops detects network latency and proposes adding an ingress rule in a security group to bypass a blocked gateway. The compiler normalizes this into contract Cfw , which the evidence collector binds to service-health metrics, incident ticket ID, and securitygroup configurations. Because modifying firewall rules alters production network posture, the scorer assigns a high blast-radius score, mapping Cfw to autonomy level L4 . If the proposed source range is public (0.0.0.0/0), the policy engine routes the contract to SQAP LUS H UMAN. SQA validators review the proposal; a security-archetype validator holds veto power. If approved, the airlock signs certificate Ωfw . The broker verifies Ωfw and evaluates the state drift-check predicate Φdrift before executing the API call.

The controller monitors signals from the ledger, validator mesh, policy engine, broker, and compliance tools. Triggers apply globally or to a scoped domain d (action class, service, region), as shown in Table 7. When a trigger fires, the controller applies one or more scoped withdrawal mechanisms (Table 8). Withdrawal is enforced at admission (the airlock consults suspension state before emitting Ω) and execution (the broker checks revocation state before execution). If the broker cannot obtain fresh revocation state (e.g., due to a network partition), it fails closed, rejecting all highconsequence (L3 , L4 ) executions. Revocation updates are signed, versioned, and distributed as monotonically increasing epochs. Deployments that cache revocation state must bound cache lifetime and record the revocation epoch used for every broker decision. 5.2

Case Studies

The following case studies trace SAB’s certificate-bound admission boundary across four operational settings (Table 9).

Certificate-bound authority must be withdrawable. An incident may require immediate suspension across an action class, domain, validator, or execution path, so revocation and suspension are part of the control plane rather than an external operations procedure. 5.1

Incident Response Workflow and Override Risk

(7)

Equation 7 applies to pending or unexecuted certificates. Completed executions cannot be undone; instead, the ledger marks Ω for post-hoc response and compensating actions. 7

Table 6: Comparison of certification and auditing artifacts. Artifact

Records

Limitation

Audit log Policy decision record SQA quorum SAB certificate

Executed event, actor, time Policy engine query result Validator votes and reasoning Full pre-execution admission state

Lacks admission context. Omits semantic evidence and validator votes. Lacks system-level context and revocation epoch. Outcomes require ledger-bound records and replay overhead.

Table 7: System revocation triggers. Trigger Class

Primary Signal

Institutional Consequence

Validator Degradation Evidence Outage/Staleness

Validator agreement rate or accuracy drops below threshold Telemetry streams, incident tickets, or configs become stale/unavailable Updated policy version Pver published or rolled back System monitor detects live intrusion or active severity-1 outage Suspected leak of signing keys or broker execution credential Operator triggers emergency hold or manually rolls back change

Downgrade autonomy level, quarantine validator Airlock rejects new proposals in affected domain

Policy Drift/Rollback Environmental Outage Compromised Identity Operational Anomaly

definitions. The broker deploys only certified manifests and monitors rollout health, recording outcomes.

sensitivity term, raising uncertainty if payloads are unclassified. If policy forbids autonomous export of the data class, the path is P ROHIBITED or R EJECT. If export is permitted with redaction, the airlock enforces a minimization contract, routing the redacted export through compliance validators and human multi-signature.

Failure Prevented and Artifact. The broker blocks unverified code from reaching production by rejecting proposals with missing rollbacks, failing tests, or unapproved dependencies. The certificate records all build and test evidence, enabling post-deployment replay. 6.3

Failure Prevented and Artifact. This path is intended to prevent autonomous leakage of regulated data under the guise of diagnostic utility. The airlock rejects overbroad exports or destinations lacking compliance controls, binding redaction attestations and human approvals to the export outcome.

Case Study 3: Sovereign AI Cloud

Scenario and Path. A sovereign operator uses a mixed model stack (external and domestic models) for planning. An external model proposes restarting services and exporting diagnostic telemetry. The local contract compiler decomposes the plan into separate contracts, and the collector binds local evidence (data-residency tags, configuration states). Sensitive context is held locally. The local policy engine enforces jurisdictional rules, rejecting contracts that violate residency policies or cross borders. Valid proposals are reviewed by local SQA validators, and high-stakes actions route to human operator multi-signature. The local broker executes approved contracts using domestic identities.

7

Evaluation Methodology and Targets

We evaluate SAB’s control-plane feasibility and performance tradeoffs with a Go prototype and three workload families. 7.1

Prototype Implementation

Our prototype of SAB in Go contains a stateless admission service, Protocol Buffer and JSON Schema contract definitions, an evidence-digest generator extracting Kubernetes and Active Directory logs, OPA/Rego policy evaluation, Ed25519 signing for Ω, a PostgreSQL ledger, prototype target adapters, revocation epoch distribution, and a replay command-line interface. The target adapters simulate actions on Kubernetes and AWS/GCP APIs.

Failure Prevented and Artifact. The local broker path prevents external planning models from directly acquiring execution authority. External reasoning systems cannot obtain credentials, bypass jurisdictional policies, or execute mutations without local admission and replay. Certificate Ω records the domestic validation path and broker identity, making sovereign execution verifiable. 6.4

Invalidate active certificates, re-evaluate paths Advance revocation epoch ρrev , suspend domain Revoke pending certificates, rotate execution keys Immediate human-only fallback, cancel active certificates

7.2

Evaluation Methodology and Baselines

We compare SAB against standard baseline security controls (Table 10) using 500 execution contracts: 200 cloudinfrastructure contracts (security groups, scaling, restarts, credential rotations), 150 CI/CD contracts (rollbacks, patch deployments, manifest updates), and 150 data-governance contracts (migrations, log exports, resource deletion).

Case Study 4: Regulated Data Workflow

Scenario and Path. During an incident, an agent proposes exporting database logs for offline analysis. The logs may contain PII or regulated customer records. The compiler translates this into a data-export contract detailing source tables, destinations, and redaction rules. The collector binds schema metadata and legal-hold status. The scorer assigns a high data-

7.3

Experimental Setup

Table 11 reports preliminary measurements from a singlenode local workstation testbed, not a production cloud de8

Table 8: Authority withdrawal mechanisms. Mechanism

Enforcement Point

Operational Effect

Level Downgrade Domain Suspension Certificate Invalidation Validator Quarantine Identity Rotation Human-only Fallback Replay Sweep

Consequence Scorer Assurance Airlock Sovereign Broker SQA Mesh Sovereign Broker Assurance Airlock Audit Service

Caps maximum permitted autonomy level L(C), routing actions to human approval. Categorically rejects all future proposals matching the suspended domain d. Broker rejects execution of unexecuted certificates matching the revoked class. Removes compromised or stale validators from participating in quorum validation. Rotates execution credentials, invalidating certificates bound to stale keys. Bypasses automated routing, requiring manual approval for all actions. Re-evaluates recent certificates under updated policy to identify active safety violations.

Table 9: Case-study summary. Case

Proposed Action

Risk

Certification Path

Outcome

Enterprise Cloud Operations

Open security-group rule during outage Deploy agent-generated patch

Public exposure, privilege expansion, incident masking Security regression, failed rollout, irreversible change Jurisdictional leakage, external execution authority PII exposure, retention violation, cross-boundary transfer

SQAP LUS H UMAN or R E -

Vetoed, escalated, or executed through broker with Ω Certified artifact deployed with rollback and outcome evidence Local certificate Ω and sovereign execution identity required Redacted export, human approval, or denial with replay record

Generated-Code Deployment Sovereign AI Cloud Regulated Data Workflow

Execute plan proposed by external foundation models Export logs or datasets for diagnosis

ployment. The topology contains one admission service, one policy engine, one PostgreSQL-backed ledger, one revocation service, three broker processes, three target-service adapters, and two workload-driver processes. The 500 contracts are independently labeled by three expert systems/security engineers for expected admission decision, certification path, and safety outcome, with disagreements resolved by majority vote and discussion. We ran five full-workload trials (2,500 admission attempts). Live local measurements include admission, OPA evaluation, Ed25519 signing, ledger writes, broker verification, revocation-epoch propagation, and SQA latency using a three-validator mesh with 2-of-3 quorum, Ed25519-signed attestations, and a security-archetype veto. Kubernetes, Active Directory, and cloud-control-plane evidence is replayed from captured or synthetic traces; target mutations are simulated by service adapters. Unless a row states otherwise, latency results are p50; SQA admission reports p50/p95, and rate metrics are percentages. 7.4

SQA or SQAP LUS H U MAN

SQAP LUS H UMAN under local policy SQAP LUS H UMAN, R E JECT, or P ROHIBITED

threat categories, and states the authority-boundary invariants. 8.1

Threat Model and TCB Boundaries

The threat model assumes that the agent runtime may be compromised (e.g., via prompt injection or credential theft) or faulty. Upstream evidence sources, SQA validators, and operators may also fail. We assume the integrity of the core control-plane components. Table 12 maps the TCB boundaries. 8.2

Threat Analysis

Table 13 maps SAB’s controls and residual risks across ten threat categories: agent compromise, validator failure, policy degradation, operational bypass, and authority creep. 8.3

Authority-Boundary Invariants

The threat analysis yields four invariants for high-stakes agentic infrastructure: • Proposal is not authority: Agent proposals must compile to C and be admitted by the airlock before execution. • Approval is evidence-bound: Validator and human approvals must be cryptographically bound to C and H(E). • Execution is sovereign: Infrastructure changes must execute through IDexec at the broker, never via agent credentials. • Authority is revocable and replayable: Certificates, validators, and autonomy levels must be revocable; decisions must be reconstructable from the ledger. Under the stated trust assumptions, admitted autonomous actions are bounded by contract, evidence, certification path, broker verification, and revocation state, and remain auditable through the ledger.

Target Metrics and Expected Tradeoffs

Table 11 reports the evaluation targets and measured results, grouped into latency overheads, routing accuracy, and storage metrics. These measurements indicate control-plane feasibility on a single workstation, not production cloud performance. SAB trades latency for assurance, additional control-plane components for replayability, and occasional false escalation for lower under-classification risk. SQA and manual reviews add latency; evidence collection and ledger writes add storage and processing overhead while supporting audit and replay.

8

JECT

Security Analysis

SAB mitigates authorization risks by decoupling proposal generation from execution through certificate-bound admission. The analysis defines the threat model, examines ten 9

Table 10: System baselines and comparison matrix. Baseline

Mechanism

Assurance Limitation

Static IAM/Policy Human Approval Only Audit Logging Only LLM Self-Review SQA without SAB SAB (No Revocation)

Checks static roles (e.g., AWS IAM, OPA) Routes all proposals to human change queue Records actions to security log after execution Proposing model critiques its own output Quorum validation of individual proposed actions Airlock admission without broker revocation checks Fixed high-stakes certification path for all actions

Context-unaware; permits structurally valid but semantically unsafe actions. Introduces high latency; prone to rubber-stamping due to review fatigue. No runtime prevention; cannot halt unauthorized actions before they occur. Susceptible to hallucinations and adversarial jailbreaks; no institutional control. Lacks system-level context: no evidence binding, revocation, or execution decoupling. Vulnerable to stale certificates during outages or policy changes.

SAB (No Routing)

High operational friction for low-risk actions; excessive latency.

Table 11: Preliminary, workload-dependent evaluation results. Metric names specify p50, p95, mean, or percentage. Metric

Prototype Target

Measured Result

Expected Tradeoffs

PolicyOnly admission latency (p50) SQA admission latency (p50/p95) Broker verification latency (p50) Revocation propagation latency (p95) Schema replay completeness (%) Unsafe admission rate (%) Routing accuracy (%)

< 5 ms report p50/p95 by validator config < 1 ms < 100 ms 100% lower is better agreement with expert-labeled oracle > 60% < 10 KB / action

1.84 ms 185 ms / 380 ms 0.15 ms 12.4 ms 100% 0.4% 96.8%

Fast path for low-consequence rules (OPA check). Parallel validator queries. Signature and active revocation epoch check. Delay to propagate new ρrev to local brokers. Fraction of ledger entries with replayable schema context. Admissions that violate safety policy or human intent. Agreement of consequence scorer with expert-labeled paths.

68.2% 3.4 KB

Actions automated compared to a human-only queue. Space required on the evidence ledger per contract.

Human approval reduction (%) Certificate storage overhead (mean)

Table 12: Trusted and untrusted components in the SAB threat model. Component

TCB Status

Failure Mitigation

Agent runtime SQA validators

Untrusted proposer Untrusted external oracles Outer engine: untrusted; signature verifier: trusted Trusted control plane Trusted control plane Trusted control plane

Airlock interposition, rate limiting Diversity, vetoes, signing keys

Evidence collector

Policy / revocation Airlock and broker Evidence ledger

9

rects latency and validator overhead to operations where mistakes have material operational, legal, or security outcomes. Operational Sovereignty. SAB defines sovereignty operationally: the institution must maintain local control over policy evaluation, evidence retention, signing keys, revocation state, broker identity, and execution authority. External foundation models are restricted to proposal generation; they hold no production credentials and cannot bypass local certification and revocation.

Freshness, cryptographic provenance verification Versioned policies, epoch gating Hardened runtimes, key rotations Cryptographic chains, backups

Discussion and Limitations

Composition with OpenKedge Layers. In the OpenKedge stack, OpenKedge provides bounded mutation interfaces; SAL separates planning from execution; VAI provides execution identity and evidence chains; PDD validates generated code against schemas and protocol obligation invariants; and SQA evaluates action-level semantics. SAB composes these layers into a system-level admission boundary.

SAB limits when model reasoning can transition into system mutations. It does not guarantee that planning models are correct or aligned. The main operational questions concern review granularity, proportional assurance, sovereignty, composition, and residual risk. 9.1

Operational Discussion 9.2

Human Oversight and the Unit of Review. Traditional human-in-the-loop controls are prone to fatigue and rubberstamping, especially when operators are presented with raw reasoning transcripts or unconstrained tool calls. SAB changes the unit of review: operators approve a normalized contract C, cryptographic evidence digest H(E), consequence level L(C), and validator outputs. Approval is tied to a concrete contract, evidence snapshot, and policy context.

System Limitations

SAB’s security claims depend on several operational and design boundaries: • Consequence Scoring Errors: Consequence classification (R(C)) is an operational classifier. It may underestimate risk when dependencies are hidden, or create bottlenecks by over-estimating risk and over-escalating low-risk tasks to human review. • Evidence Staleness and Incompleteness: SAB relies on external telemetry and log sources. Stale or incomplete evidence can cause the airlock to certify actions under assumptions that no longer hold. • Validator and Policy Calibration: SQA relies on validators whose reliability degrades after model, prompt,

Proportional Assurance. Autonomy should be granted dynamically. The same agent may restart a stateless container (routed to P OLICYO NLY), but require SQA for rollbacks, human multi-signature for firewall modifications, and be prohibited from deleting databases. Consequence-aware routing di10

Table 13: Threats, controls, and residual risks. Threat

SAB Control

Residual Risk

Malicious proposer agent

Decouples proposal from execution; requires contract C and signed certificate Ω.

Compromised validator

Enforces validator diversity and critical archetype vetoes; signature quarantine.

Correlated validator failure

Diversity rules across model architectures and prompt structures.

Stale/manipulated evidence Forged/replayed certificate Policy downgrade attack Human rubber-stamping

Binds evidence digests H(E); enforces freshness and provenance checks. Sovereign broker verifies σSAB with pkSAB , validity window Tvalid , and epoch ρrev . Binds signed, versioned policy releases Pver ; enforces monotone routing. Structured evidence presentation; role separation; approval trends analysis.

Emergency-mode abuse Jurisdictional bypass Autonomy creep

Scoped emergency authority; short-lived certificates; mandatory post-hoc replay. Location checks in policies; regional checks at the sovereign broker. Autonomy level caps L(C); periodic ledger audits.

Bad proposals may consume validator and operator review capacity. A compromised validator can approve unsafe actions until quarantined. Shared latent training biases may still fail to catch novel semantic errors. Upstream telemetry sources may report inaccurate state. Compromise of airlock private key requires key rotation. Authorized policy updates may be overly permissive. Humans may still sign off negligent changes under operational pressure. Social or operational abuse of emergency procedures. Incomplete or inaccurate asset tagging. Slow normalization of deviance.

or workload changes. Additionally, SAB cannot correct policies that are incomplete, stale, or contradictory. • Prototype Generality: Prototype results are workloaddependent and should not be interpreted as general performance guarantees. • Emergency Bypass Risk: Outages may force operators to bypass normal assurance rules. While SAB records emergency overrides and enforces short validity windows, emergency access remains a critical threat vector. • Control-Plane Attack Surface: SAB introduces highvalue security targets (signing keys, the ledger, and the broker). Compromise of these trusted components invalidates all security properties. These limitations motivate an incremental deployment strategy, starting with high-consequence domains (IAM, network policy, and deployments) and expanding as evidence pipelines and validator models mature.

10

cated nodes [10, 11, 14]. They do not verify whether those transitions are semantically correct or compliant with institutional rules. SAB treats authority as a separate admission question. Access Control (IAM) and Policy Engines. Zero trust, IAM, and policy-as-code engines (e.g., OPA) enforce static permissions at API endpoints [7–9, 15]. They are necessary inputs, but they authorize identities rather than validating autonomous proposals against live evidence. SAB adds proposal certification before broker execution. AI Safety and Tool Governance. Agent safety tools (filters, sandboxes, critiques) reduce dangerous outputs from planning models [1, 16]. They run as unprivileged utilities and cannot serve as control-plane security boundaries. In SAB, safety models can act as untrusted validators in the SQA mesh, but authority is released only by the airlock and broker.

Related Work

We position SAB relative to systems security and safety mechanisms that partially address proposal admission, execution control, and auditability:

Audit Logs and Evidence. Audit trails and transparency logs capture events for post-incident forensics [17]. Certificate Ω binds pre-execution admission evidence, policy versions, and validator outputs; ledger-bound outcome record O links subsequent observations to Ω, making admission decisions replayable. Audit logs record executed events; the SAB certificate records the admission context that authorized execution.

Runtime Assurance. Safety-monitor architectures (e.g., Simplex) supervise autonomous controllers and interpose fallback modes to prevent physical safety envelope violations [4, 5, 13]. The same interposition pattern can be applied to cloud and software control planes, where the monitored objects are discrete configuration changes, evidence freshness, and policy epochs.

Sovereign AI Governance. Sovereignty frameworks dictate local resource control and residency rules [18]. In SAB, those requirements appear as local policy evaluation, domestic validator meshes, and regional execution brokers, so external or mixed planning models cannot bypass local control boundaries. Existing mechanisms authorize identities, replicate decisions, monitor runtime behavior, or record events. SAB combines these mechanisms into an admission boundary that decides when autonomous proposals may become execution authority.

Assurance Cases. Dependability and safety cases structure claims, assumptions, and evidence for pre-deployment system certification [6]. SAB brings a similar claim-evidence structure into runtime admission: approvals bind to specific contracts, evidence snapshots, and revocation state. Distributed Consensus. Paxos, Raft, and PBFT protocols ensure ordered agreement on state transitions across repli11

11

Conclusion

[8] AWS. Aws identity and access management (iam) user guide. In Amazon Web Services Technical Documentation, 2024. [9] Open Policy Agent. Policy language. Open Policy Agent documentation, 2026. Accessed 2026-06-05. [10] Leslie Lamport. The part-time parliament. ACM Transactions on Computer Systems (TOCS), 16(2):133–169, 1998. [11] Diego Ongaro and John Ousterhout. In search of an understandable consensus algorithm. In Proceedings of the USENIX Annual Technical Conference (ATC), pages 305–320, 2014. [12] OWASP Foundation. OWASP top 10 for large language model applications. OWASP project page, 2025. [13] Dzung Phan, Radu Grosu, Nils Jansen, Nicola Paoletti, Scott A. Smolka, and Scott D. Stoller. Neural simplex architecture. In NASA Formal Methods Symposium, pages 97–114, 2020. [14] Miguel Castro and Barbara Liskov. Practical byzantine fault tolerance. In Proceedings of the Symposium on Operating Systems Design and Implementation (OSDI), pages 173–186, 1999. [15] Kubernetes. Dynamic admission control. Kubernetes documentation, 2026. Accessed 2026-06-05. [16] Hakan Inan, Kartikeya Upasani, Jian Zhang, Rashi Rungta, Riza Aktas, Felipe Cruz, Jason Ramapuram, Stephen Hicks, Onur Dilek, Igor Molybog, et al. Llama Guard: LLM-based input-output safeguard for humanAI conversations. arXiv preprint arXiv:2312.06674, 2023. [17] Luc Moreau and Paolo Missier. PROV-DM: The PROV data model. Technical report, World Wide Web Consortium, 2013. [18] National Institute of Standards and Technology. Artificial intelligence risk management framework (AI RMF 1.0). Technical Report NIST AI 100-1, National Institute of Standards and Technology, 2023.

Agentic infrastructure needs an authorization boundary between plausible model-generated proposals and privileged production mutations. The Sovereign Assurance Boundary (SAB) addresses that boundary through certificate-bound admission: agent outputs compile into execution contracts C; admission decisions bind those contracts to evidence digests H(E), certification paths, policy versions, revocation epochs, and scoped broker identities; and execution proceeds only after the sovereign broker verifies the certificate Ω. The paper’s core claim is intentionally narrow: SAB is not a replacement for IAM, formal verification, consensus, or human review, but a runtime admission path that composes those mechanisms so autonomous reasoning alone cannot become execution authority. The prototype and case studies show that the airlock–broker model can be implemented and measured across cloud operations, generated-code deployment, sovereign AI cloud settings, and regulated data workflows, while the limitations identify the remaining dependencies on evidence freshness, policy quality, validator calibration, and trusted control-plane components. SAB therefore treats delegated execution authority as certificate-bound, evidencebound, revocable, and replayable, rather than as an ambient permission.

References [1] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. ReAct: Synergizing reasoning and acting in language models. arXiv preprint arXiv:2210.03629, 2022. [2] Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. Toolformer: Language models can teach themselves to use tools. arXiv preprint arXiv:2302.04761, 2023. [3] Jun He and Deying Yu. Semantic quorum assurance: Collective certification for non-deterministic ai infrastructure. arXiv preprint arXiv:2606.08021, 2026. [4] Lui Sha. Using simplicity to control complexity. IEEE Software, 18(4):20–28, 2001. [5] Roderick Bloem, Bettina Könighofer, Robert Könighofer, and Chao Wang. Shield synthesis: Runtime enforcement for reactive systems. In Proceedings of the International Conference on Tools and Algorithms for the Construction and Analysis of Systems (TACAS), pages 533–548, 2015. [6] John Rushby. Security assurance cases: Motivation and research agenda. System Safety Society, 2001. [7] Scott Rose, Oliver Borchert, Stu Mitchell, and Sean Connelly. Zero trust architecture. Technical Report Special Publication 800-207, National Institute of Standards and Technology (NIST), 2020. 12