Sovereign Assurance Boundary: Certificate-Bound Admission for Agentic Infrastructure

Securing agentic infrastructure requires integrating model-generated proposals with existing safety and security mechanisms.

Semantic Quorum Assurance (SQA) verifies locally whether an action is semantically admissible (e.g., whether a security-group 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 $\Omega$ contains the evidence and validation epoch required by policy.

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.

R2: Contractual Admission.

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

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 $\mathcal{R}(C)$ (blast radius, irreversibility, data risk, and uncertainty).

R5: Sovereign Execution.

Admitted contracts must execute exclusively through an institutionally controlled broker that scopes credentials and validates the certificate $\Omega$.

R6: Revocability.

The system must support scoped withdrawal, enabling key rotation, validator quarantine, and domain suspension.

R7: Replayability.

SAB must record the certificate $\Omega$ and, after execution, outcome record $O$ in an append-only log, with the ledger binding $O$ to $\Omega$.

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 $\Gamma_{\mathrm{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 $pk_{\mathrm{SAB}}$ denote the airlock’s public verification key and $\sigma_{\mathrm{SAB}}$ its signature on the certificate $\Omega$.

Under the trust model in Section 3.1, SAB enforces five authority-boundary invariants:

P1: Proposal-Execution Decoupling Invariant.

Let $\mathrm{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 $\mathrm{Mutate}(r,op)$ without first being admitted by the airlock:

$$\mathrm{Execute}(\Omega)\implies\mathrm{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 $\Omega$ and its airlock signature:

$$\mathrm{Execute}(\Omega)\implies\operatorname{Verify}(pk_{\mathrm{SAB}},\Omega,\sigma_{\mathrm{SAB}})\land C\in\Omega$$

where the certificate is bound to the specific contract $C$, policy version $P_{\mathrm{ver}}$, execution identity $ID_{\mathrm{exec}}$, and validity window $T_{\mathrm{valid}}$.

P3: Evidence-Binding Invariant.

Approvals and validator attestations ($\Gamma_{\mathrm{SQA}},\Gamma_{\mathrm{human}}$) are bound cryptographically to $C$ and the evidence digest $H(E)$:

$$\operatorname{Approve}(C,H(E))\implies\mathrm{Sign}(\Gamma,C\mathbin{\|}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 $\operatorname{CertPath}(C)$ are satisfied:

$$\operatorname{Admit}(C)\implies\operatorname{VerifyPath}(C,\operatorname{CertPath}(C))$$

where $\operatorname{CertPath}(C)$ depends on the consequence score $\mathcal{R}(C)$, autonomy level $\mathcal{L}(C)$, and policy version $P_{\mathrm{ver}}$. 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 $\Omega$ if the current revocation epoch $\rho_{\mathrm{active}}$ is greater than the certificate’s revocation epoch $\rho_{\mathrm{rev}}$, or if the execution time $t_{\mathrm{exec}}$ falls outside the validity window $T_{\mathrm{valid}}$:

$$\mathrm{Execute}(\Omega)\implies\rho_{\mathrm{rev}}=\rho_{\mathrm{active}}\land t_{\mathrm{exec}}\in T_{\mathrm{valid}}$$

The broker therefore rejects certificates from stale epochs.

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.

Consider an operations agent $\mathcal{A}_{\text{ops}}$ proposing an ingress network rule $C_{\mathrm{fw}}$ to resolve an outage. Table 4 traces this proposal through the reference architecture.

The example has two failure cases:

• •

  Airlock policy rejection: If $\mathcal{A}_{\text{ops}}$ attempts to open port 22 (SSH) to the public internet (0.0.0.0/0), the consequence scorer maps this high-risk action to $L_{4}$. The airlock’s security-archetype validator detects a policy violation and triggers a critical veto, returning $\mathrm{Reject}$.

• •

  Broker-side verification failure: If $C_{\mathrm{fw}}$ is admitted at time $t_{1}$, but before execution at $t_{2}$ the active revocation epoch advances from $\rho_{1}$ to $\rho_{2}$, the broker detects that $\rho_{\mathrm{rev}}=\rho_{1}<\rho_{2}$ and aborts the execution. Similarly, if the broker’s drift-check predicate $\Phi_{\mathrm{drift}}(E_{\mathrm{fw}},S_{t_{2}})$ evaluates to false (indicating that the target security group’s state has drifted since admission), the execution is aborted.

Let $C$ be an execution contract, $E$ be the evidence bound to that contract, $S_{t}$ be the observed infrastructure state at time $t$, $\mathcal{R}(C)$ be the consequence score, and $\mathcal{L}(C)$ be the assigned autonomy level; the certificate $\Omega$ is the resulting admission artifact. The airlock implements the admission function:

$$\operatorname{Airlock}(C,E,S_{t})\rightarrow\Omega\;\;\text{or}\;\;\mathrm{Reject}.$$

The function returns $\Omega$ only when the proposal satisfies the required certification path. Otherwise, it returns $\mathrm{Reject}$. To prevent time-of-check to time-of-use (TOCTOU) risks, the broker evaluates a state drift-check predicate $\Phi_{\mathrm{drift}}(E,S_{t_{\mathrm{exec}}})$ immediately before executing the mutation, verifying that the live state at execution time $S_{t_{\mathrm{exec}}}$ has not deviated from the bound evidence $E$ beyond policy safety margins.

The consequence score $\mathcal{R}(C)$ quantifies the operational, compliance, and security risk of the contract:

$$\mathcal{R}(C)=\alpha B(C)+\beta P(C)+\gamma D(C)+\delta I(C)+\eta 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 ($\alpha,\beta,\gamma,\delta,\eta$), 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 $\mathcal{P}_{\mathrm{inst}}$, and jurisdictional constraints $\mathcal{J}$, the airlock maps the contract to an autonomy level:

$$\mathcal{L}(C)=\Lambda(\mathcal{R}(C),\mathcal{P}_{\mathrm{inst}},\mathcal{J}).$$

Table 5 defines the consequence-aware autonomy levels.

After assigning $\mathcal{L}(C)$, the airlock routes the contract through a certification path:

$$\operatorname{CertPath}(C)\rightarrow\left\{\begin{array}[]{@{}l@{}}\mathrm{Reject},\ \mathrm{PolicyOnly},\\ \mathrm{LightweightQuorum},\ \mathrm{SQA},\\ \mathrm{SQAPlusHuman},\ \mathrm{Prohibited}\end{array}\right\}.$$

(2)

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.

To admit a contract, the airlock evaluates the admission predicate:

	$\displaystyle\operatorname{Admit}(C)={}$	$\displaystyle\Phi_{\mathrm{policy}}(C)\land\Phi_{\mathrm{evidence}}(C,E)$		(3)
		$\displaystyle\land\Phi_{\mathrm{assurance}}(C)\land\Phi_{\mathrm{authority}}(C).$

• •

  $\Phi_{\mathrm{policy}}(C)$: Policy permits the action class and target resource.

• •

  $\Phi_{\mathrm{evidence}}(C,E)$: Required evidence exists, is fresh, and has trusted provenance.

• •

  $\Phi_{\mathrm{assurance}}(C)$: The selected assurance path completed successfully.

• •

  $\Phi_{\mathrm{authority}}(C)$: The broker identity, validity window, and revocation state are valid.

When the admission predicate is satisfied, the airlock issues the certificate $\Omega$:

	$\displaystyle\Omega=\langle$	$\displaystyle C,\ H(E),\ \mathcal{R}(C),\ \mathcal{L}(C),$		(4)
		$\displaystyle\operatorname{CertPath}(C),\ \Gamma_{\mathrm{SQA}},$
		$\displaystyle\Gamma_{\mathrm{human}},\ ID_{\mathrm{exec}},\ T_{\mathrm{valid}},$
		$\displaystyle P_{\mathrm{ver}},\ \rho_{\mathrm{rev}},\ \sigma_{\mathrm{SAB}}\rangle.$

where $ID_{\mathrm{exec}}$ is the execution identity, $T_{\mathrm{valid}}$ is the validity window, $P_{\mathrm{ver}}$ is the policy version, $\rho_{\mathrm{rev}}$ is the revocation epoch, and $\sigma_{\mathrm{SAB}}$ is the airlock signature. After execution, the broker emits a separate outcome record:

$$O=\langle\Omega,\ \mathrm{status},\ t_{\mathrm{exec}},\ H(S_{\mathrm{post}}),\ \mathrm{result},\ \sigma_{\mathrm{broker}}\rangle,$$

(5)

where $\sigma_{\mathrm{broker}}$ is the broker signature. The ledger stores $O$ and binds it to $\Omega$.

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 $\Omega$) 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 high-consequence ($L_{3},L_{4}$) 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.

Let $d$ be a domain or action class. Suspension is a future-admission invariant:

$$\operatorname{Suspended}(d)\implies\forall C\in d,\;\operatorname{Admit}(C)=\mathrm{False}.$$

(6)

The invariant is evaluated before path selection, preventing suspended domains from being bypassed.

Certificate revocation is an execution invariant:

$$\operatorname{Revoked}(\Omega)\implies\operatorname{Execute}(\Omega)=\mathrm{False}.$$

(7)

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

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.

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 $\Omega$, 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.

We compare SAB against standard baseline security controls (Table 10) using 500 execution contracts: 200 cloud-infrastructure 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).

Table 11 reports preliminary measurements from a single-node local workstation testbed, not a production cloud deployment. 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.

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.

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.

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

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 $ID_{\mathrm{exec}}$ 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.

SAB’s security claims depend on several operational and design boundaries:

• •

  Consequence Scoring Errors: Consequence classification ($\mathcal{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, or workload changes. Additionally, SAB cannot correct policies that are incomplete, stale, or contradictory.

• •

  Prototype Generality: Prototype results are workload-dependent 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 high-value 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.