Sovereign Execution Broker: Enforcing Certificate-Bound Authority in Agentic Control Planes
arXiv:2606.20520v2 [cs.CR] 19 Jun 2026
Jun He OpenKedge.io
Deying Yu OpenKedge.io
Abstract
or adversarial prompt injection can trigger unauthorized or destructive infrastructure mutations. To mitigate these risks, recent architectures have introduced institutional admission gates such as the Sovereign Assurance Boundary (SAB) [1] to certify agentic proposals before they are executed. SAB evaluates proposed actions against safety and operational contracts, producing a cryptographically signed certificate (Ω) upon successful validation. However, an admission certificate is not enforcement unless the target infrastructure mutation paths actively require a broker to verify it. In the OpenKedge stack, Semantic Quorum Assurance (SQA) validates proposed actions, SAB certifies admitted authority, and SEB enforces the resulting certificates at mutation time. If agents or their runtime wrappers continue to hold standing production credentials, the assurance layer can be bypassed entirely. For example, a compromised wrapper or a direct API execution path could allow an agent to perform actions without ever submitting its proposals to the admission gate. Moreover, even when an agent complies with the admission process, the time lag between proposal admission and actual execution creates a window of vulnerability where the underlying state can drift, or the security environment can change. To address this gap, we introduce the Sovereign Execution Broker (SEB). As shown in Figure 1, SEB is the runtime enforcement boundary for certificate-bound agentic control planes. In the intended deployment, no agent runtime holds standing mutation credentials. Instead, all autonomous mutation requests must go through the SEB, which acts as the custodian of execution authority. At the moment of mutation, SEB verifies the SAB certificate, matches the request against the certified contract, checks revocation and drift, mints short-lived scoped credentials, executes the mutation, and logs signed decision or outcome records.
Autonomous agents are increasingly connected to cloud, deployment, and data-control workflows, but production mutation authority should not reside inside non-deterministic reasoning processes. Existing access-control mechanisms authorize identities, while assurance layers certify proposed actions; neither alone provides a mandatory enforcement point for certified authority at the moment of mutation. This paper introduces the Sovereign Execution Broker (SEB), a runtime enforcement boundary for certificate-bound agentic infrastructure. SEB consumes certificates issued by the Sovereign Assurance Boundary (SAB), verifies that the requested mutation matches the certified execution contract, checks validity windows, policy epochs, revocation epochs, and live-state drift, mints scoped execution identity, invokes infrastructure APIs, and records signed decision and outcome records. By separating proposal, admission, and execution, SEB turns certified authority into a short-lived, revocable, auditable runtime capability, provided that production mutation APIs reject non-broker identities. We present the SEB execution model, certificate and replay-verification predicates, scoped identity semantics, bypass-prevention deployment patterns, failure behavior, and a concrete prototype implementation. We evaluate the prototype on AWS and Kubernetes clusters, measuring latency overheads, revocation propagation, drift detection, and security under fault injection.
1
Introduction
As autonomous systems powered by Large Language Models (LLMs) transition from passive analytical assistants to active operational planners, they are increasingly integrated into production infrastructure. Today, autonomous agents are tasked with auto-scaling compute groups, deploying containers, configuring cloud security groups, and managing databases. However, because these agents use non-deterministic reasoning processes, granting them direct access credentials creates severe security and operational risks. A single hallucination
Contributions. 1
This paper makes four contributions:
Agent Proposal
Decision / Outcome Ledger
SAB Boundary
Scoped Mutation
Table 1: SEB compared to existing authorization and safety enforcement mechanisms.
Certificate Ω
Sovereign Execution Broker
Figure 1: OpenKedge pipeline from agent proposal to runtime enforcement. In the intended deployment, the Sovereign Execution Broker is the only autonomous-path entity possessing credentials to mutate state, which it does only upon verifying a valid certificate Ω and writing signed decision or outcome records to the ledger.
1. Broker-enforced autonomy. We identify the enforcement gap between certified autonomous proposals and actual infrastructure mutation, and define the Sovereign Execution Broker as the runtime boundary that prevents autonomous agents from holding or exercising standing production credentials.
Enforces
Missing
IAM OPA
Identity permissions Policy predicates
Audit Log
After-the-fact record
SAB
Admission certificate
Proposal semantics Certificate-bound authority Pre-execution prevention Mutation-time enforcement
SEB
Certificate-bound execution
2.1
Requires mandatory mutation-path deployment
Why IAM is Insufficient
Traditional Identity and Access Management (IAM) systems are designed under the assumption of human-driven or static programmatic execution. An IAM policy typically answers a binary authorization query: “Is this principal (e.g., identity or role) authorized to perform this API operation on this resource?”
2. A certificate-verification execution model. We formalize the broker execution interface Execute(Ω, req, St , P latf orm) → D | O, where the broker verifies the SAB certificate Ω, matches the requested mutation against the certified contract C, checks validity windows, policy epochs, revocation epochs, and live-state drift before executing.
In agentic control planes, this model fails. Autonomous agents reason dynamically and non-deterministically; thus, granting an agent static IAM credentials means trusting all subsequent logic generated by that agent. If the agent’s prompts are hijacked or its reasoning loop fails, those static permissions allow the agent to execute arbitrary destructive operations (e.g., deleting databases or opening public ports). In contrast, a Sovereign Execution Broker (SEB) evaluates a much richer context. Rather than validating static identity permissions, SEB answers:
3. Scoped execution identity and revocation-beforeexecution. We introduce a least-privilege identity model in which credentials are minted only at execution time, scoped to the certified contract, target resource, validity window, and revocation epoch. This ensures that pending certificates can be invalidated before mutation and that agents never receive reusable mutation authority.
“Is this specific, certified mutation request still valid under the current system evidence, active policy epoch, revocation epoch, live-state drift, and cryptographic scope?” By shifting authorization from the identity to the certified action itself, SEB removes standing mutation credentials from agent runtimes when the deployment denies all non-broker mutation identities.
4. Prototype implementation and empirical evaluation. We implement the broker as a Go service with adapters for AWS STS and Kubernetes TokenRequest, and deploy it as a mandatory mutation path. We evaluate the prototype under realistic workloads, reporting p50, p95, and p99 execution latencies, microbenchmarks for cryptographic and drift validation, revocation propagation delays, and behavior under induced partition and crashrecovery scenarios.
2
Mechanism
2.2
Why SAB Needs a Broker
The Sovereign Assurance Boundary (SAB) provides institutional admission control by validating the semantic safety of proposed agent actions [1]. At the conclusion of validation, SAB emits a signed certificate Ω. However, Ω is merely a cryptographic assertion. Without a runtime broker that acts as the sole credential holder, Ω becomes a post-hoc audit artifact. An agent could easily bypass the admission process by calling APIs directly using standing credentials, or execute expired/invalidated certificates.
Background and Motivation
SEB is motivated by a mismatch between identity-centric access control and certificate-bound autonomous mutations. 2
• Target Infrastructure: The cloud APIs (e.g., AWS, GCP) or orchestrators (e.g., Kubernetes) undergoing mutations.
Therefore, SAB and SEB form a complementary pair: SAB decides whether a proposal may become authority at admission time, whereas SEB enforces that authority at the moment of mutation. 2.3
• Revocation Service: A service maintaining the current global policy and revocation epoch ρactive .
Running Example
To illustrate the need for SEB, consider a security group change where an autonomous agent Aops is tasked with opening a firewall port for a new service.
• Ledger: An append-only log capturing the detailed outcomes of broker decisions and executions.
1. Proposal: Aops proposes a contract Cf w to open port 443 to CIDR 10.0.0.0/16.
• Identity Provider / IAM: The system (e.g., AWS STS, Kubernetes token issuer) that mints credentials.
2. Admission: SAB validates Cf w against corporate firewall policy and issues certificate Ωf w .
• Evidence Sources: Distributed monitors supplying realworld state evidence to both SAB and SEB.
3. Intervening Event: Before execution, the security environment drifts: the subnet is decommissioned, or a global emergency revocation epoch advances.
3.2
We partition the system components into trusted boundaries and untrusted or fallible components:
4. Runtime Check: When the wrapper requests execution, the SEB intercepts the request and checks the live state St . Because the target subnet is invalid or the certificate’s epoch is stale, SEB rejects the execution.
Trusted Components.
5. Execution: If all checks pass, SEB mints a short-lived IAM token bound strictly to the target security group and the port-opening operation, executes it, and logs the outcome.
• The SAB signing key, the SEB signing key, and the corresponding public verification keys. • The global Revocation Epoch Service, which distributes epoch updates.
System and Threat Model
• The local Cloud Provider’s Identity Provider (IdP) for minting short-lived session credentials.
The SEB threat model separates untrusted autonomous planning from trusted admission, broker execution, and targetplatform enforcement. 3.1
We assume the integrity of:
• The SEB execution environment (e.g., running within a secure enclave or highly restricted private network segment).
This flow prevents the agent from holding standing credentials to edit the security group, and the broker rejects replay under drifted conditions, assuming the cloud API rejects non-broker mutation identities.
3
Trust Assumptions
• The target platform’s IAM, RBAC, admission-control, and policy-enforcement mechanisms that reject mutation identities outside the broker path.
System Components
The system consists of the following components: • The append-only properties of the Ledger.
• Agent Runtime: An untrusted, non-deterministic reasoning loop (e.g., an LLM-based agent) that plans and proposes infrastructure mutations.
Deployment Assumptions. The enforcement theorem in Section 9 relies on three operational configuration assumptions. First, no agent runtime or wrapper possesses standing credentials that authorize production mutation. Second, we define authorized mutation principals as the broker role plus broker-issued execution sessions created after certificate verification; target APIs accept mutation requests only from this set. Third, emergency break-glass identities are outside the autonomous agent path and are separately authenticated, authorized, and audited.
• SAB Admission Boundary: The trusted admission gateway that intercepts proposals, verifies their safety using Semantic Quorum Assurance (SQA) or policy engines, and emits cryptographically signed certificates Ω. • Sovereign Execution Broker (SEB): The trusted execution boundary that intercepts all mutation requests, verifies certificates, checks live state, and performs execution. 3
4
Untrusted or Fallible Components. We do not assume the security or correctness of:
Broker Execution Model
The core of the SEB architecture is a formal verification and execution pipeline over certificates, execution requests, live target state, platform scopeability, signed DecisionRecords, and signed OutcomeRecords.
• The Agent Runtime or its internal prompting context. • Individual semantic validators within the SQA quorums, which may be compromised or exhibit model bias.
4.1 • Local operators or administrators (who could attempt malicious emergency overrides).
The Sovereign Execution Broker acts as a gatekeeper. It consumes an SAB certificate Ω, a concrete execution request req, the live state of the target infrastructure St , and a platform descriptor that captures the target API’s native scoping mechanisms. The interface is defined as:
• Live target-state observations, which may be delayed due to eventual consistency. 3.3
Broker Execution Interface
Execute(Ω, req, St , P latf orm) → D
Threat Model
or
O
(1)
where D is a signed D ECISION R ECORD for verification rejection or non-execution, and O is a signed O UTCOME R ECORD for a target mutation attempt. An admitted contract is represented as:
The security objective of SEB is to ensure that, within the deployment assumptions above, production mutations occur only through broker verification of authorized, fresh certificates. We consider an adversary who can compromise the agent runtime, inject prompts, intercept network packets, or manipulate the target state between the time of certificate issuance and execution. Specifically, SEB defends against the following threat vectors:
C = (op, target, params, constraints, risk_level) (2) where op is the intended API operation, target is the resource or endpoint to mutate, params is the proposed payload, constraints contains policy-level bounds on the mutation, and risk_level records the assurance tier under which the action was admitted. A SAB certificate is represented as:
• Broker Bypass: The agent attempts to directly invoke cloud APIs using standing credentials, bypassing both admission gates and the broker. • Stale Certificate Replay: The adversary captures a previously executed certificate Ω and attempts to replay it to execute the mutation again.
Ω = (cid, C, Eadmit , Tvalid , Pver , ρrev , nonce, issuer, σSAB )
(3)
where cid is the contract identifier, Eadmit is the evidence state used during admission, Tvalid is the certificate validity interval, Pver is the admitted policy version, ρrev is the revocation epoch at admission time, nonce is a single-use freshness value, issuer identifies the SAB admission boundary, and σSAB is the SAB signature over the canonical certificate body. An execution request req is represented as a tuple:
• Request-Certificate Mismatch: The agent receives a certificate for a safe mutation (e.g., restarting a service) but submits a request for a destructive operation (e.g., terminating the database). • Time-of-Check to Time-of-Use (TOCTOU) Drift: The state of the infrastructure changes between the time SAB issues the certificate and when SEB receives it, rendering the original contract dangerous.
req = (cid, op, target, params, caller, texec , nonce) (4)
• Stale Epoch / Revocation Bypass: The certificate is revoked or the system’s global security policies are upgraded, but the agent tries to use an older certificate.
where: • cid: The unique identifier of the contract C validated by SAB.
• Overbroad Credential Abuse: The agent attempts to leverage session credentials minted for a specific resource to mutate unrelated resources.
• op: The requested operation or API action. • target: The target infrastructure resource or endpoint identifier.
• Broker Partition: The agent attempts to execute mutations during a network partition that prevents the broker from contacting the Revocation Service.
• params: The exact parameters supplied to the API operation. 4
Table 2: Broker verification checks, inputs, and records emitted on failure. Check
Input
Failure Record
Signature Φsig Contract match Φmatch Validity Φtime Policy epoch Φpolicy Revocation Φrev Drift Φdrif t Replay Φreplay Scopeability
Ω, σSAB req, Ω, C Tvalid Pver , Pactive ρrev , ρactive Eadmit , St cid, nonce, L C, P latf orm
D: reject D: reject D: reject D: reject/re-admit D: fail closed D: reject/re-admit D: reject D: reject if false
• Φrev : Confirming that the certificate has not been revoked (ρrev = ρactive ). • Φdrif t : Confirming that the live target state St has not drifted beyond the admitted evidence state Eadmit described in the certificate. • Φreplay : Confirming that (cid, nonce) has not previously been reserved or executed in the broker ledger. • Scopeable(C, P latf orm): Confirming that the required action, resource, time, and parameter constraints are enforceable by the target platform or by a mandatory broker-controlled proxy/admission path. Equivalently, the match predicate binds the request to the certificate identifier and nonce before comparing the target contract:
• caller: The identity of the agent wrapper requesting execution. • texec : The timestamp of the execution request.
Φmatch = (req.cid = Ω.cid)∧
• nonce: The certificate nonce that must be unused in the broker ledger.
4.2
(req.nonce = Ω.nonce)∧ M atch(req.op, req.target, req.params, C). (6)
Verification Pipeline
The policy predicate is:
When a request is submitted, the broker runs it through the pipeline shown in Figure 2. The stage predicates and their failure outcomes are summarized in Table 2. 4.3
Φpolicy = (Pver = Pactive )
The Scopeable predicate is true only when every constraint in C is enforceable on the mutation path. Native IAM/RBAC conditions can make action, resource, time, or namespace constraints scopeable. A mandatory proxy or admission controller is another mechanism that makes parameterlevel constraints scopeable when native policy languages cannot express them. If neither native policy nor a mandatory broker-controlled interposition point can enforce a constraint, Scopeable(C, P latf orm) is false and the broker rejects before credential minting. The replay predicate is:
Formal Certificate Verification Predicate
Execution is admissible only if the verification predicate evaluates to true. Let V = V erif yExec(Ω, req, St , P latf orm, L), where L is the broker ledger: V = Φsig ∧ Φmatch ∧ Φtime ∧ Φpolicy ∧ Φrev ∧ Φdrif t ∧ Φreplay
(7)
(5)
∧ Scopeable(C, P latf orm)
Φreplay (cid, nonce, L) = ((cid, nonce) ∈ / Lused )
• Φsig : Asserting the validity of SAB’s cryptographic signature σSAB on Ω.
The broker must atomically reserve (cid, nonce) before minting an execution identity or invoking the target API. A second request carrying the same certificate nonce is rejected even if the first execution failed after reservation.
where:
• Φmatch : Confirming that req.cid = Ω.cid, req.nonce = Ω.nonce, and the requested operation, resource, and parameters match the contract C embedded inside Ω.
(8)
Nonce Reservation, Idempotency, and Crash Recovery. Nonce reservation is conservative: once (cid, nonce) is reserved, retry is not allowed unless crash recovery can prove that no mutation was attempted. A proof may come from a durable pre-invocation ledger state, an idempotency token accepted by the target platform, or target-side evidence showing that the mutation did not occur. If the broker crashes after the point where target invocation may have happened, the certificate is treated as consumed; the agent must re-admit the proposal through SAB before another mutation attempt.
• Φtime : Confirming texec lies within the certificate’s validity window Tvalid . • Φpolicy : Validating that the certificate policy version matches the active policy version: Φpolicy = (Pver = Pactive ). 5
Input Ω, req, St
Φsig Signature
Φmatch Match
Φtime Validity
Φpolicy Policy Epoch
Φrev Revocation
Φdrif t Drift
Scopeable Platform
Mint IDexec
API Mutation
Outcome Record O
Decision Record D
Figure 2: Broker verification pipeline. The request req, certificate Ω, and live state St flow sequentially through cryptographic and state checks. Verification failures produce signed decision records; only if all checks pass is a short-lived execution identity minted and the API mutation attempted. 4.4
DecisionRecord and OutcomeRecord Binding
• Escalate: Human break-glass handling is outside the autonomous certificate-bound path and is discussed in Section 10.
If verification fails before target invocation, SEB generates a D ECISION R ECORD D: D = DecisionRecord(did, cid, nonce, decision, f ailed_check, reason, tdecide , σbroker )
5
(9)
SEB shifts mutation authority from identity-centric authorization to certificate-bound scoped authorization.
where decision records whether the request was rejected, failed closed, or required re-admission. Every verification failure produces a signed DecisionRecord that binds the rejection reason to the certificate and nonce. If verification succeeds and the broker invokes the target mutation API, SEB generates an O UTCOME R ECORD O representing the target attempt:
5.1
(10)
error, σbroker ) where oid is the outcome ID, status indicates target success or target failure, H(Spost ) is the hash of the target infrastructure’s post-state evidence when available, and σbroker is the broker’s digital signature binding the outcome to the original certificate and nonce. OutcomeRecords are therefore evidence of attempted mutations, not of verification failures. 4.5
The Problem with Standing Credentials
In typical cloud environments, agents or their runtime wrappers are assigned static IAM roles with generic permissions (e.g., ec2:* or eks:* privileges). Under this model, there is no enforcement mechanism preventing a wrapper or hijacked agent from bypassing the admission controller. An agent can issue a direct API request to mutate resources outside of any certified contract. To prevent bypass, we must enforce a strict constraint:
O = OutcomeRecord(oid, cid, nonce, status, tstart , tend , result, H(Spost ),
Scoped Execution Identity
Agents and their wrappers must possess zero standing mutation credentials. Instead, the SEB is the only entity with the authority to assume powerful administrative roles. 5.2
Failure Behavior
Bypass Prevention Deployment Pattern
SEB is an enforcement boundary only when it is installed as the mandatory mutation path. The target platform must reject mutation calls from agent identities, developer workstations, and ordinary service roles, and must accept production mutation only from authorized mutation principals as defined in Section 3. Without this deployment pattern, an agent with standing credentials can bypass both SAB and SEB.
If any check in the verification pipeline fails, SEB behaves according to defined policies: • Reject: Immediate rejection of execution request, returning a standard authorization error and writing a signed decision record. • Re-admit: For transient failures like minor drift or policy mismatches, the broker writes a decision record and can request the agent to re-submit its proposal to SAB.
AWS. An AWS deployment uses a deny-by-default organization and account configuration. Service Control Policies (SCPs) deny high-risk mutation actions unless the principal is the broker role or a broker-issued session carrying required session tags such as seb:cid, seb:nonce,
• Fail Closed: If the revocation status service is unreachable or if a signature check fails, SEB blocks the request and writes a fail-closed decision record. 6
Table 3: Scoped identity dimensions and their enforcement mechanisms.
seb:issuer, and seb:risk. Agent roles have permission boundaries that exclude production mutation APIs and permit only proposal submission and read-only evidence collection. The broker role alone may call sts:AssumeRole into target execution roles. Those target roles require brokerset session tags and external IDs, constrain session duration to the certificate validity window where supported, and attach inline STS session policies for action and resource restrictions. IAM conditions and resource tags enforce native bounds such as action, resource ARN, namespace/account, source VPC endpoint, and principal tag. When AWS IAM cannot express a parameter-level constraint, such as a specific ingress port or JSON payload field, the mutation must flow through a brokerowned proxy adapter that validates the payload against C immediately before forwarding it to the AWS API and binding the result to the ledger.
Enforcement
Action
Native IAM/RBAC operation where supported (e.g., AWS security-group ingress) Native resource ARN, namespace, object name, or label selector Native conditions, or mandatory broker proxy/admission validation against C STS duration, projected-token expiration, and broker validity check over Tvalid Session tags, admission metadata, and ledger binding to Ω and nonce Broker validation that Pver = Pactive Broker validation that ρrev = ρactive before minting
Resource Parameters Time
Certificate Policy Revocation
Kubernetes. A Kubernetes deployment separates agent service accounts from mutation service accounts. Agent service accounts receive RBAC permissions for proposal creation and observation but no verbs such as create, update, patch, or delete on protected resources. The broker service account is the only account authorized to perform those verbs in protected namespaces, and it uses shortlived TokenRequest credentials or impersonation only after certificate verification. A validating admission webhook rejects protected mutations unless the request carries brokerattested context, such as seb.openkedge.io/cid and seb.openkedge.io/nonce annotations or equivalent admission-review metadata. A mutating webhook may stamp broker-approved metadata onto objects before the validating webhook checks it. Policy engines such as Gatekeeper, Kyverno, or ValidatingAdmissionPolicy can enforce invariants that RBAC cannot express, while the broker adapter validates payload fields that remain outside native policy expressiveness. The security theorem below depends on these RBAC and admission controls rejecting direct non-broker mutation attempts. 5.3
Dimension
validation, admission control, required session tags, and ledger binding. 5.4
Scope Dimensions
The down-scoped identity restricts execution along several dimensions. These dimensions are detailed in Table 3. For instance, in the firewall example, AWS session policy can restrict the session to ec2:AuthorizeSecurityGroupIngress on the target security-group ARN and to a short duration, while session tags bind the credential to the certificate identifier and nonce. If IAM cannot express the exact port or CIDR constraint for the relevant API, the broker-owned proxy adapter validates port=443 and the approved CIDR against C before forwarding the call; the ledger then records the certificate, nonce, request payload, and outcome. Thus native authorization enforces what the platform supports, and SEB supplies the reference-monitor logic for the remaining certificate-bound constraints.
SEB Identity Model
Rather than executing actions using its own master credentials, the SEB acts as a token broker. Upon verifying a certificate Ω, the broker programmatically requests the Identity Provider (IdP) to mint a temporary, down-scoped execution credential IDexec :
5.5
Security Properties
The scoped execution identity model provides several security properties under the deployment assumptions in Section 3: • No Standing Credentials: Agents never hold credentials that can be abused out-of-context.
IDexec = M intIdentity(C, Ω, target, scope, Tvalid , ρrev ) (11) Native IAM or RBAC systems enforce the dimensions they can express, typically action, resource, principal, session duration, audience, and namespace. Parameter-level constraints and certificate binding are not uniformly enforceable by cloud IAM. When the target API cannot enforce a dimension directly, SEB preserves the binding through broker-side proxy
• Least Privilege: Tokens are restricted to the minimum required API permissions for the requested task. • Constrained Reuse: Tokens are bound to a short expiration window (60 seconds for Kubernetes projected tokens, and the minimum supported 900 seconds for 7
is safe under Eadmit and signs the certificate Ω. However, the certificate may not be presented to the SEB for execution until a later time t2 (where t2 > t1 ). During this interval t2 − t1 , the target infrastructure can change. For example, another process may modify security group rules, rotate access keys, or decommission target virtual machines. If the broker executes the certificate blindly without checking for state changes, a certified action that was safe at t1 could become unsafe or policy-violating at t2 .
Assurance Certificate Ω
• Contract C • Target Resource • Action & Parameters
Scope Bindings
• Validity Window Tvalid • Revocation Epoch ρrev
6.2
To prevent execution on stale state, SEB implements a live drift check. Before executing any mutation, the broker queries the target infrastructure’s current state St2 and compares it to the evidence state Eadmit captured inside Ω. We define the drift predicate Φdrif t as:
Short-Lived Execution Identity IDexec
Figure 3: Scoped identity binding. The broker extracts the safety parameters, target resources, and validity windows from Ω and maps them into a short-lived execution identity IDexec plus any required broker-side enforcement bindings.
Φdrif t (Eadmit , St2 ) = Distance(P roject(Eadmit ), P roject(St2 )) ≤ ϵC
• P roject(·): A projection function extracting only the state variables relevant to contract C. • Distance(·): A distance or divergence metric measuring the discrepancy between the admitted state and the live state.
• Revocation-Before-Execution: If the certificate is revoked before execution, the broker will refuse to mint the token, preventing the action from occurring even if it was previously approved.
• ϵC : The policy-defined drift tolerance limit for contract C.
• Replay Resistance: The broker reserves the certificate nonce before mutation and rejects subsequent requests carrying the same (cid, nonce) pair.
If the distance exceeds ϵC , the broker rejects the certificate, rendering the action invalid.
• Accountability: Every broker decision and mutation attempt is logged, providing cryptographic evidence linking the executor’s identity to the original SAB certificate, decision record, and outcome record where a target invocation occurred.
6.3
Epoch-Based Revocation
In addition to target state changes, corporate policy or operational requirements may change after a certificate is signed. Rather than keeping track of long, distributed revocation lists (CRL), we employ a global revocation epoch counter ρactive . Each certificate Ω contains the revocation epoch ρrev at which it was signed. At the moment of execution, the broker verifies: ρactive = ρrev ⇒ executable (13)
Drift, Revocation, and TOCTOU Protection
Distributed control planes introduce a vulnerable interval between action admission and runtime execution. SEB closes that interval with live-state drift checks and epoch-based revocation. 6.1
(12)
where:
AWS STS). While nonce reservation prevents repeated broker-mediated minting, exposure of an already minted 900-second AWS STS credential is bounded by session policies, session tags, the proxy path, and target IAM conditions, preventing out-of-context reuse.
6
Drift Predicate
If the system has advanced the global epoch (e.g., due to an active security incident or policy change) such that:
The TOCTOU Problem in Agentic Systems
ρactive > ρrev ⇒ Reject
When SAB evaluates an agent proposal at time t1 , it does so based on the admitted evidence state Eadmit = Et1 gathered at that moment. SAB certifies that the proposed contract C
(14)
the certificate is rejected immediately. Figure 4 shows the timeline of this process. 8
t1
t2
t3
Table 4: Compact summary of the SEB research prototype artifacts.
t4
t Agent requests execution of Ω
SAB admits C, signs Ω (ρrev = k) Revocation epoch advances to k + 1
Broker rejects Ω (stale ρrev )
Figure 4: Revocation-before-execution timeline. Between admission (t1 ) and execution request (t3 ), the active revocation epoch advances (t2 ), causing the broker to reject the request (t4 ). 6.4
Language Lines of Code (LoC) Broker Replicas Database Backend
Go v1.21 4,200 LoC (excluding tests) 3 replicas (high-availability mode) PostgreSQL v15 (Amazon RDS db.r6g.xlarge) AWS STS, Kubernetes TokenRequest AWS Mutation Proxy, Kubernetes Validating Webhook Go standard library crypto/ed25519 Local sync.Map, 5-sec poll interval, 5-sec TTL AWS EKS v1.28 (worker instances: m6i.xlarge)
Cryptographic Library Revocation Caching Deployment Environment
Fail-Closed Semantics • pkg/revocation: The polling client that interacts with the Revocation Epoch Service and maintains the local thread-safe epoch cache. • pkg/ledger: The database client managing PostgreSQL storage for nonces, decision records, and outcome records.
• Unreachable Revocation Service: If SEB cannot query the active global epoch ρactive , it assumes ρactive > ρrev and rejects.
• pkg/adapter: Platform-specific adapters including the AWS Security Token Service (STS) and Kubernetes TokenRequest adapters.
• Drift Evaluation Failure: If target APIs fail to return live state metrics or evidence is incomplete, SEB rejects the transaction.
• pkg/proxy: The reverse proxy for parameter-level API validation.
• Stale Policy Epoch: If the current policy version exceeds the policy epoch indicated in Ω, the request is rejected and forced to undergo re-admission.
7.2
Certificate Parser and Verifier
The certificate verifier consumes SAB certificates (Ω) and validates their authenticity. We use Go’s standard crypto/ed25519 library for cryptographic operations. To prevent signature-malleability exploits, certificates are parsed and checked against a strict JSON schema, then marshaled using a deterministic Canonical JSON serialization (sorting keys alphabetically, removing optional whitespace, and escaping strings per RFC 8785) before signature verification. The verifier loads SAB’s public verification key from a secure local trust store, extracts the contract C, and validates the signature σSAB over the canonical certificate body.
This fail-closed design prevents an attacker from isolating the broker to exploit older, compromised certificates.
System Implementation
We have implemented a concrete research prototype of the Sovereign Execution Broker (SEB) in Go, consisting of approximately 4,200 lines of code. The codebase is structured into modular packages with clean boundaries to separate cryptographic verification, state monitoring, ledger writing, and platform-specific credential minting. A compact summary of the system implementation artifacts is presented in Table 4. 7.1
Value / Implementation Choice
Scoped Identity Adapters Enforcement Components
Under high-assurance levels (specifically L3/L4 within the OpenKedge framework), the broker enforces a strict failclosed policy. In the event of system partitions, network latency, or service failures, SEB defaults to rejecting the request. Specifically:
7
System Aspect
7.3
Nonce Reservation and Replay Protection
To prevent replay attacks, SEB implements an atomic nonce reservation mechanism using a PostgreSQL database. When an execution request is received, the broker initiates a database transaction and attempts to insert the (cid, nonce) pair into a reserved_nonces table:
Codebase Structure and Boundaries
The broker’s codebase is divided into the following primary components: • cmd/seb-broker: The entry-point daemon that hosts the gRPC and HTTP/JSON endpoints.
CREATE TABLE reserved_nonces ( cid UUID NOT NULL, nonce VARCHAR(64) NOT NULL, reserved_at TIMESTAMP NOT NULL, PRIMARY KEY (cid, nonce)
• pkg/verifier: The verification pipeline that parses certificates, verifies signatures, checks validity intervals, and matches requests to contracts. 9
Revocation Epoch Cache
Agent / Wrapper gRPC Request
Ledger (PostgreSQL)
Go Broker Service (Ed25519 Verifier)
Outcome Binding Cloud STS Adapter (Session Policies)
Cloud / Kubernetes APIs (Mutation)
Figure 5: System deployment architecture of the Sovereign Execution Broker. The Go-based service verifies certificates, interacts with active local caches, calls cloud STS or Kubernetes APIs for scoped session credentials, invokes mutations through brokercontrolled adapters/proxies, and logs signed decision and outcome records to PostgreSQL.
);
7.5
Because of the primary key constraint, duplicate requests fail the insertion and are immediately rejected. This prevents double-spend attacks even under highly concurrent execution requests.
The broker maintains a thread-safe local cache of the global policy version Pactive and revocation epoch ρactive using a sync.Map. A background worker polls the centralized gRPC Revocation Service over a TLS connection every 5 seconds. To enforce fail-closed behavior, the local cache has a TTL of 5 seconds. If a network partition prevents the broker from contacting the revocation service, the cache expires after 5 seconds, and all subsequent certificate validations fail closed until connectivity is restored.
7.4
Decision and Outcome Ledger
Every verification decision and execution outcome is logged to PostgreSQL. The schemas are defined as:
7.6
CREATE TABLE decision_records ( did UUID PRIMARY KEY, cid UUID NOT NULL, nonce VARCHAR(64) NOT NULL, decision VARCHAR(32) NOT NULL, failed_check VARCHAR(32), reason TEXT, t_decide TIMESTAMP NOT NULL, signature BYTEA NOT NULL );
Policy and Revocation Cache
Scoped Identity Adapters
The broker implements two credential-minting adapters: • AWS STS Adapter: Evaluates the contract C and calls the AWS STS AssumeRole API, requesting the minimum supported session duration of 900 seconds. While nonce reservation prevents repeated broker-mediated minting, exposure of an already minted 900-second AWS STS credential is bounded by session policies, session tags, proxy path, and target IAM conditions, preventing out-of-context reuse.
CREATE TABLE outcome_records ( oid UUID PRIMARY KEY, cid UUID NOT NULL, nonce VARCHAR(64) NOT NULL, status VARCHAR(32) NOT NULL, t_start TIMESTAMP NOT NULL, t_end TIMESTAMP NOT NULL, result TEXT, post_state_hash VARCHAR(64), error TEXT, signature BYTEA NOT NULL );
• Kubernetes TokenRequest Adapter: Invokes the Kubernetes core token projection API (/api/v1/ namespaces/{ns}/serviceaccounts/{sa}/ token) via the Go client-go SDK. It requests a short-lived token (expiration window of 60 seconds) bound to the target namespace, service account, and audience. 7.7
Cloud Proxy and Admission Webhooks
To enforce constraints that native IAM and RBAC cannot express (such as parameter-level validation like restricting port ranges or container images), SEB implements inline enforcement components:
Every record is signed by the broker using its private Ed25519 key, ensuring non-repudiation and providing an audit trail for security teams. 10
Table 5: Metrics used in the empirical evaluation of the SEB prototype.
• AWS Mutation Proxy: A secure HTTP/HTTPS reverse proxy that intercepts mutation requests. The agent wrapper directs its API requests to this proxy, which uses the dynamically minted scoped STS credentials. The proxy parses the request payload, validates parameter constraints against the contract C (e.g., verifying that the CIDR block and ports match the certified contract), and forwards the request to the cloud endpoint.
Broker verification latency
Latency added by signature, epoch, and contract checks Time required to mint transient tokens from IAM/STS Elapsed time from epoch advancement to request rejection Percentage of mutations rejected due to live-state drift Rate of invalid or uncertified mutations that succeed Number of concurrent certified mutations executed per second Disk storage write overhead in bytes per transaction
Revocation propagation delay Drift rejection rate Unsafe execution escape Throughput Ledger overhead
8
Trusted Computing Assumptions and Failure Handling
System Evaluation
We evaluated our Go-based SEB research prototype to assess its latency overhead, throughput scalability, revocation propagation delay, and enforcement capability under injected security threats and system faults. Our evaluation answers the following research questions:
Trusted Computing Base (TCB): We assume the broker runs in a secure, isolated execution environment (e.g., AWS Nitro Enclaves or a dedicated Kubernetes private network segment). We trust the integrity of the broker’s private signing key, the SAB public key store, the PostgreSQL database, and the target platform’s root IAM/RBAC mechanisms. Failure and Crash Recovery: If the broker crashes after nonce reservation but before invoking the target API, the execution request fails closed, and the nonce remains consumed. The agent must re-request admission from SAB to obtain a fresh certificate. To prevent double mutation, the broker passes an idempotency token (computed as H(cid ∥ nonce)) to the target platform (e.g., via the AWS ClientRequestToken parameter or Kubernetes client uid). Upon broker recovery, if the status of a reserved nonce is uncertain, the broker queries the target API using the idempotency token to determine if the mutation occurred, logging the result before releasing the transaction lock. Where target APIs do not expose reliable idempotency or lookup mechanisms, SEB conservatively treats the certificate as consumed and requires re-admission through SAB.
7.9
Meaning / Operational Description
Scoped credential latency
• Kubernetes Validating Webhook: A validating admission webhook service (implemented using Go’s sigs.k8s.io/controller-runtime) that intercepts Kubernetes resource modifications. The webhook rejects any mutation that does not carry the seb.openkedge.io/cid and seb.openkedge.io/nonce annotations matching a successfully reserved nonce and valid certificate in the broker’s ledger.
7.8
Metric
• RQ1 (Latency Overhead): What latency overhead does SEB add to infrastructure mutations? • RQ2 (Revocation Propagation): How quickly does a global revocation epoch advancement prevent pending executions? • RQ3 (Credential Minting Cost): What is the computational and network cost of dynamic scoped credential issuance? • RQ4 (Drift Detection): How does the drift check perform under live state queries, and what is its overhead? • RQ5 (Comparative Advantage): How does broker enforcement compare to direct IAM, static policy checks, or audit-only configurations? • RQ6 (Fault Containment): How does SEB behave under network partitions, broker crashes, or malformed certificate attacks?
Artifact Availability
The SEB research prototype, including the Go gRPC and HTTP broker service, AWS and Kubernetes adapters, validating webhook manifests, benchmark harness scripts, and detailed reproducibility instructions, will be released publicly as open-source software as part of the OpenKedge artifact repository.
8.1
Experimental Setup
Our experimental setup consists of a Kubernetes cluster (Amazon EKS v1.28) deployed in the AWS us-west-2 region. 11
Table 6: Broker verification microbenchmarks (5,000 trials).
• Broker Nodes: The Go-based broker service runs as a high-availability deployment with 3 replicas. Each replica is hosted on an AWS EC2 m6i.xlarge instance (4 vCPUs, 16 GiB RAM) running Linux.
Pipeline Component Ed25519 Signature Verification (Φsig ) Certificate Parsing & Canonicalization Contract Matching (Φmatch ) Epoch Check (Φpolicy , Φrev ) (Cache Hit) Epoch Check (Φpolicy , Φrev ) (Cache Miss) PostgreSQL Nonce Reservation (Φreplay ) PostgreSQL Ledger Write (Async Append) AWS STS Credential Minting (AssumeRole) Kubernetes TokenRequest API
• Database Backend: We use Amazon RDS PostgreSQL v15 (db.r6g.xlarge) as our ledger and nonce storage backend. • Network Topology: All broker nodes, the database instance, and the Revocation Service reside within a private VPC. The average network latency between broker instances and the RDS PostgreSQL instance is 1.1 ms. • Certificates: SAB certificates are generated using Ed25519 signatures, ranging in size from 512 bytes (minimal IAM resource policy) to 1.5 KB (complex policies containing multiple parameter-level constraints).
p50 Latency (ms)
p99 Latency (ms)
0.08
0.11
0.12
0.18
0.05 0.03
0.08 0.05
2.40
3.82
3.20
5.12
3.50
5.60
46.70
158.40
12.10
18.30
capturing tail latency anomalies. The AWS SDK for Go was configured such that transient network retries were enabled up to three times, while retry-on-throttling was disabled so STS rate limits appeared directly in throughput measurements.
• Revocation Cache: The local cache polls the gRPC Revocation Service every 5 seconds, with a cache TTL of 5 seconds.
8.2
• Credential Duration: Projected service account tokens are requested with a 60-second duration, and AWS STS credentials are minted with the minimum allowed session duration of 900 seconds.
Verification Microbenchmarks (Exp 1)
We first measured the execution latency of each check in the verification pipeline. Table 6 reports the p50 and p99 latencies over 5,000 trials at a fixed single-request steadystate concurrency (concurrency = 1). The cryptographic validation (Φsig , parsing, and contract matching) contributes less than 0.3 ms of total latency. The primary latency bottlenecks are the network round-trips to external services: the database write for nonce reservation ( 3.2 ms) and, most dominantly, AWS STS credential minting ( 105.2 ms).
Methodology and Simulation Boundary. All latency and throughput measurements for the baseline configurations and Full SEB were collected using live cloud and database APIs in AWS. Specifically, our broker-side operations interacted directly with active AWS STS AssumeRole endpoints, the live Kubernetes core TokenRequest API, and our RDS PostgreSQL database instance. The live drift checks performed real queries to active AWS EC2 Security Groups and EKS cluster APIs. Conversely, for the security and fault-injection experiments (reported in Section 8.5), network partitions of the revocation service and database crash events were simulated within our controlled test-harness environment to prevent permanent disruption to our active AWS cloud infrastructure.
8.3
End-to-End Latency and Baselines (Exp 2)
We compared the end-to-end performance of SEB against several baselines across two workloads: • K8s Patch: Updating pod replicas or container configurations in the EKS cluster. • AWS Security Group Update: Intercepting and executing an ingress firewall rule authorization.
Statistical Methodology. To ensure statistical rigor, we adopted a strict measurement policy. For each configuration and workload, we ran 100 warm-up execution cycles to prime Go runtime caches, connection pools, TLS sessions, and database/client-side caches, after which we executed 5,000 official trials. Tables 6–9 report latency measurements collected at a fixed concurrency level of a single-request steady-state (concurrency = 1) over 5,000 trials. To evaluate scalability, we conducted a separate experiment scaling request concurrency from 1 to 100 threads, with the throughput results reported in Figure 6. The latency values are summarized using p50, p95, and p99 percentiles rather than simple arithmetic averages,
We report the baseline latency measurements in Table 7 (Kubernetes workload) and Table 8 (AWS workload), separating the broker-side overhead from the estimated client-observed end-to-end latency. Note that SAB admission latency is excluded from all configurations because the evaluation isolates mutation-time enforcement overhead. The measurements are separated into two distinct metrics: • Broker-Only Overhead: The total latency added solely by the broker service, comprising certificate signature verification, database nonce reservation, live drift check 12
Table 7: Kubernetes workload latency comparison (p50, p95, p99) showing broker-only overhead and estimated client endto-end latency. Broker-Only (ms)
Estimated Client E2E (ms)
Direct RBAC Static Policy Proxy (Gatekeeper) Audit-Only Logging SAB without Broker Enforcement
0.00 / 0.00 / 0.00 8.50 / 11.20 / 12.30
12.50 / 15.20 / 19.80 21.00 / 26.40 / 32.10
0.00 / 0.00 / 0.00 0.00 / 0.00 / 0.00
12.70 / 15.40 / 20.10 12.60 / 15.30 / 19.90
Full SEB (Ours) – SEB without drift checks – SEB without revocation checks – SEB without nonce reservation
28.20 / 36.50 / 47.10 16.10 / 21.30 / 27.80 28.10 / 36.40 / 47.00
40.70 / 51.70 / 66.90 28.60 / 36.50 / 47.60 40.60 / 51.60 / 66.80
25.00 / 32.20 / 41.50
37.50 / 47.40 / 61.30
Configuration
out drift) reduces the broker-only overhead by 85.3 ms because it eliminates the need to query the AWS API (DescribeSecurityGroups) to verify the subnet state. Removing the database nonce reservation (SEB without nonce reservation) saves 3.2 ms of database write time. 8.4
To decompose the performance overhead of the broker, we analyze the latency contributions of individual sub-steps in Table 9. This breakdown demonstrates that target state drift checking (42.9% for Kubernetes, 62.3% for AWS) and scoped credential minting (42.9% for Kubernetes, 34.1% for AWS) constitute the vast majority of the overhead. In contrast, local validation logic represents a negligible portion of the overhead.
Table 8: AWS workload latency comparison (p50, p95, p99) showing broker-only overhead and estimated client end-toend latency. Broker-Only (ms)
Estimated Client E2E (ms)
Direct IAM Static Policy Proxy (OPA) Audit-Only Logging SAB without Broker Enforcement
0.00 / 0.00 / 0.00 8.20 / 10.10 / 12.10
85.00 / 98.40 / 112.50 93.20 / 108.50 / 124.60
0.00 / 0.00 / 0.00 0.00 / 0.00 / 0.00
86.10 / 99.70 / 114.20 85.40 / 98.90 / 113.10
Full SEB (Ours) – SEB without drift checks – SEB without revocation checks – SEB without nonce reservation
136.90 / 180.40 / 284.10 51.60 / 81.90 / 166.10
221.90 / 278.80 / 396.60 136.60 / 180.30 / 278.60
136.80 / 180.20 / 283.90
221.80 / 278.60 / 396.40
133.70 / 175.90 / 279.00
218.70 / 274.30 / 391.50
Configuration
Latency Breakdown Analysis
8.5
Security and Failure-Mode Validation (Exp 3 & 5)
We evaluated the broker’s resilience through a controlled injected test suite of security threat vectors and system faults, executing 1,000 test cases for each scenario. Table 10 reports the results. In all cases, the broker successfully blocked unauthorized mutations, consistent with the enforcement predicates under the stated deployment assumptions of Theorem 1. When the Revocation Service was partitioned, the broker successfully failed closed immediately after the local cache TTL (5 seconds) expired, rejecting 100.0% of requests. Broker Crash Recovery: We simulated broker crashes during execution. Out of 50 crash events, 25 were injected prior to target API invocation. All 25 failed closed, with no mutations occurring. The remaining 25 were injected during or immediately after target API invocation. Using idempotency tokens, the recovery manager resolved the state of each pending transaction against the target cloud APIs, recording 100.0% of outcomes correctly in the ledger without duplicate mutations. Where the target platform or API lacks reliable idempotency or lookup mechanisms, SEB conservatively treats the certificate as consumed and requires re-admission through SAB.
query, scoped credential minting (STS or TokenRequest), proxy payload validation, and database ledger write. • Estimated Client End-to-End Latency: The total operation time observed by the client application, which is estimated by adding the isolated broker-only overhead to the baseline direct target API execution latency (12.50 ms for Kubernetes, 85.00 ms for AWS). This separation prevents the subtraction of target API baselines from the broker’s isolated overhead. While Direct IAM and Audit-Only configurations show the lowest latency (as they perform no runtime checks or token minting), they fail to protect against agent bypass or credential theft. SEB adds 28.2 ms broker-side overhead to Kubernetes mutations and 136.9 ms broker-side overhead to AWS security-group mutations; the resulting estimated clientobserved p50 latencies are approximately 40.7 ms and 221.9 ms when combined with direct target API latency. The ablation experiments reveal the source of this overhead. In AWS, removing the live drift check (SEB with-
8.6
Revocation Propagation Delay (Exp 3)
To measure revocation propagation delay (RQ2), we issued certificates and queued them for execution. We then advanced the global revocation epoch at the Revocation Service and measured the time until the broker rejected execution requests. With a polling interval of 5 seconds and a cache TTL of 5 seconds, the maximum observed delay from epoch advancement at the revocation service to 100% request rejection at the broker was 5.2 seconds (mean delay of 2.6 seconds). This propagation delay is bounded by the polling interval plus network propagation latency. 13
Table 9: Latency breakdown of Full SEB execution overhead. K8s Workload Pipeline Component
AWS Workload
Latency (ms)
Share (%)
Latency (ms)
Share (%)
Verification (Φsig , parsing, matching) Nonce Reservation (Φreplay ) Drift Query (Φdrif t ) Credential Minting (IDexec ) Ledger Write (Post-execution logging)
0.25 3.20 12.10 12.10 0.55
0.9 11.3 42.9 42.9 2.0
0.28 3.20 85.30 46.70 1.42
0.2 2.3 62.3 34.1 1.1
Total Overhead
28.20
100.0
136.90
100.0
Table 10: Security and failure-mode controlled injected test-suite results (1,000 cases each).
8.7
Injected Scenario
Observed Broker Behavior
Uncertified Mutation Request-Cert Mismatch Replayed (cid, nonce) Stale Policy Epoch Stale Revocation Epoch Revocation Partition Malformed Ω Live-State Subnet Drift Parameter-Level Violation
Rejected by signature verifier Rejected by contract match Rejected by DB nonce constraint Rejected by epoch check Rejected by revocation check Failed closed after cache expiry Rejected by JSON parser Rejected by drift predicate Rejected by proxy validation
Live-State Drift Sensitivity (Exp 4)
Rejection Rate
Unsafe Escape Rate
100.0% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0% 100.0%
0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
Throughput (req/sec) 800
We evaluated the drift-check predicate Φdrif t by modifying target resources in the background during the interval between certificate signing (t1 ) and execution request (t2 ). Under simulated configuration updates (e.g., changing security group descriptions or tags), the broker successfully detected state deviations. When the drift tolerance threshold ϵC was set to 0 (strict matching), the broker rejected 100% of requests that experienced any background modification, showing a drift rejection rate of 4.2% in our concurrent workload simulator.
8.8
K8s TokenRequest
600
400
200
AWS STS (Throttled)
Concurrency (Threads) 20
40
60
80
100
Figure 6: Throughput scalability of the SEB prototype service.
Performance Analysis (Latency and Throughput) 8.9
We analyzed the latency distribution and throughput scalability under increasing request concurrency. Latency Percentiles: For AWS workloads, the latency percentiles are p50 = 136.9 ms, p95 = 180.4 ms, and p99 = 284.1 ms. The tail latency is dominated by AWS STS API latency spikes. For Kubernetes workloads, the percentiles are p50 = 28.2 ms, p95 = 36.5 ms, and p99 = 47.1 ms, demonstrating a highly stable profile. Throughput Scalability: Figure 6 shows the throughput of the broker service under increasing concurrent threads. The Kubernetes TokenRequest adapter scales linearly, peaking at 820 requests per second at 80 threads, limited primarily by PostgreSQL transaction commit rates. Conversely, the AWS STS adapter peaks at 240 requests per second at 40 threads, beyond which AWS STS rejects requests with RequestLimitExceeded errors. This highlights cloud provider API throttling as a dominant operational bottleneck for broker deployments.
Workload Suitability Discussion
Our results show that SEB is highly suitable for high-risk, low-frequency mutation workloads. For actions like firewall rule changes, auto-scaling modifications, or database exports, the 140 ms latency overhead is negligible relative to the security assurance of complete mediation, zero standing privileges, and cryptographic non-repudiation. However, SEB is not suitable for high-frequency, microsecond-scale control loops (e.g., real-time container CPU scheduling or fast SDN routing updates). In those contexts, the overhead of database writes, cryptographic verification, and cloud provider API calls exceeds the microsecond-level latency budgets, necessitating alternative lightweight assurance patterns.
9
Security Analysis
SEB’s security claim is certificate-bound mutation under explicit trust and deployment assumptions. 14
9.1
Security Properties
• The SEB runtime, SAB signing key, revocation service, broker ledger, and target IAM/RBAC enforcement mechanisms are trusted.
The Sovereign Execution Broker enforces the following security properties when deployed as the mandatory mutation path described in Section 5.2:
• Every scope dimension claimed by Scopeable(C, P latf orm) is enforceable by the target platform or by a mandatory broker-controlled proxy/admission path.
• Property 1 (No Direct Agent Mutation - P1): If target infrastructure APIs accept mutations only from authorized mutation principals, then an autonomous agent cannot execute direct mutations on production state.
• Break-glass identities are outside the autonomous agent path and do not share credentials with agent runtimes.
• Property 2 (Certificate-Bound Execution - P2): A mutation operation op on resource target executes through SEB only after it is bound to a cryptographically valid SAB certificate Ω.
9.3
We present a formal claim regarding the security properties of the broker enforcement model.
• Property 3 (Request-Contract Matching - P3): A certificate Ω containing contract C cannot be used to authorize an execution request req unless req matches C exactly or satisfies the explicit constraints in C.
Theorem 1 (Certificate-Bound Mutation). Under the assumptions above, an untrusted agent runtime cannot cause a production state mutation on target infrastructure unless the requested mutation matches a valid, unexpired, unrevoked, unreplayed certificate issued by the admission layer, live-state drift remains within the admitted contract bounds, and the required scope is enforceable by the target platform or by a mandatory broker-controlled proxy/admission path.
• Property 4 (Revocation-before-Execution - P4): A certificate Ω can be invalidated after admission by SAB but prior to its execution by SEB by incrementing the system’s global revocation epoch ρactive . • Property 5 (Drift-Aware Execution - P5): A certificate Ω issued under stale system evidence cannot execute if the live target state St has drifted beyond the contractdefined safety threshold ϵC .
Proof Sketch. We prove the theorem by contradiction. Suppose an agent successfully causes a state mutation M at time texec on target resource R using operation op with parameters params, but at least one theorem condition is false.
• Property 6 (Scopeable Identity - P6): The broker mints transient credentials only when Scopeable(C, P latf orm) holds; native IAM/RBAC enforce action, resource, and time constraints where supported, and broker-side proxy or admission controls enforce remaining parameter-level constraints.
Case 1: Broker Bypass. The agent attempts to execute M directly without SEB. By assumption, target APIs reject all mutation identities outside the authorized mutation-principal set. The agent has no standing mutation credentials. Therefore, the target API rejects the direct request, contradicting the assumption that the agent caused M .
• Property 7 (Replay Resistance - P7): A certificate nonce can be reserved only once, so a previously used (cid, nonce) pair cannot authorize a second mutation. • Property 8 (Decision and Outcome Evidence - P8): Verification failures produce signed decision records D, while successful verification followed by target invocation produces signed outcome records O, preventing deniability about broker decisions and mutation attempts. 9.2
Safety Proof Sketch
Case 2: No Valid Certificate or Replay. The agent submits a request to SEB without a valid certificate or with a previously used nonce. The broker evaluates Φsig and Φreplay : V erif y(Ω, σSAB ) = True
Assumptions for Theorem 1
The theorem below assumes the following trusted components and deployment conditions:
Φreplay (cid, nonce, L) = ((cid, nonce) ∈ / Lused )
(15) (16)
If the signature is invalid, the broker writes a reject decision record. If the nonce has already been reserved, the broker writes a replay decision record. In both cases, no new execution identity is minted, contradicting the assumption that the broker-mediated request caused M .
• No agent runtime or wrapper has standing credentials that authorize production mutation. • Target APIs accept production mutations only from authorized mutation principals. 15
Case 3: Certificate is Expired or Revoked. Assume a certificate Ω exists but is outside Tvalid or has been revoked prior to execution, meaning ρrev < ρactive . When the broker receives the execution request, it evaluates Φtime and Φrev : Φrev = (ρrev = ρactive )
10.1
While SEB enforces automated fail-closed behavior, production systems require mechanisms to handle unexpected failures, such as networking outages or partition of the revocation service. Break-glass operation is outside the autonomous certificate-bound theorem in Section 9. It is a separate humanauthorized emergency path with independent authentication, authorization, and audit requirements:
(17)
The failed predicate causes SEB to write a decision record, reject the request, and refuse to mint IDexec . Thus, the agent cannot execute M through the broker. Contradiction.
1. Break-Glass Override: Certified human operators can sign an emergency override request Ωoverride under a policy separate from autonomous SAB certificates.
Case 4: Request-Contract Mismatch or Unsafe Drift. Assume a valid certificate Ω exists for contract C, but the agent attempts to execute a different operation, resource, or parameter set, or the live state has drifted beyond ϵC . The broker evaluates:
2. Verifiable Escalation: The broker verifies the operator’s cryptographic signature against administrative keys and executes only if the emergency policy authorizes the mutation.
Φmatch = (req.cid = Ω.cid)∧
3. Audit Trail: Every manual override generates an alert and is permanently written to the Ledger with high priority.
(req.nonce = Ω.nonce)∧ M atch(req.op, req.target, req.params, C) (18)
The presence of this path does not weaken Theorem 1 because break-glass credentials are not available to agent runtimes and are not treated as certificate-bound autonomous mutations.
and Φdrif t (Eadmit , St ). If either predicate is false, the broker writes a decision record, rejects the request, and does not mint IDexec . Therefore, the agent cannot cause M through SEB. Contradiction.
10.2
Performance Scaling and Consensus
Integrating a broker into every mutation path introduces latency. The primary bottlenecks are:
Case 5: Required Scope Cannot Be Enforced. Assume a scope dimension required by C is not enforceable by native target-platform controls or by a mandatory broker-controlled proxy/admission path. Then Scopeable(C, P latf orm) is false, so the broker writes a decision record and rejects before credential minting. Conversely, if Scopeable is true, the trusted target IAM/RBAC or mandatory broker-controlled proxy/admission path enforces the claimed action, resource, time, and parameter constraints. Thus, the agent cannot use a broker-minted identity to execute outside C. Contradiction. Therefore, under the stated assumptions, every successful production mutation attributable to an untrusted agent must pass broker verification against a valid, unexpired, unrevoked, unreplayed certificate whose contract matches the request and whose required scope is enforceable by the target platform or by a mandatory broker-controlled proxy/admission path. This proof does not claim semantic safety of the admitted proposal, which remains the responsibility of SAB and its validators; it claims enforcement of certificate-bound authority at mutation time. ■
10
Human-in-the-Loop Escalation
• Drift Checks: Querying live infrastructure state requires making API calls to cloud providers, which can take hundreds of milliseconds. • Credential Minting: Calling STS or service account APIs to generate transient tokens adds round-trip networking overhead. To mitigate these, a deployment can use concurrent queries and cached state projections where policy permits. However, maintaining strong consistency of the revocation epoch ρactive across multiple distributed broker nodes requires consensus. A deployment can use a lightweight replicated epoch store, such as a Raft-backed database, to ensure all broker nodes validate requests against the same epoch number. 10.3
Limitations
Our design has several limitations:
Discussion and Limitations
Trust in Cloud Providers. SEB relies on the target cloud provider’s IAM system to enforce the boundaries of the minted scoped token IDexec . If the provider’s IAM enforcement layer has vulnerability bugs or allows bypass, the security properties in Section 9 no longer hold.
Operational deployment of SEB involves trade-offs around human escalation paths, performance, scaling, and targetplatform expressiveness. 16
Cold-Start Latency. Minting fresh session tokens dynamically for every single mutation request prevents credential reuse, but suffers from cold-start latencies. For highthroughput microsecond-level mutation workloads, the overhead of constant credential generation can become prohibitive, necessitating token caching strategies that introduce security trade-offs.
Cross-Cloud and Multi-Account Deployments. In heterogeneous multi-cloud environments (spanning AWS, Azure, Google Cloud, and Kubernetes), maintaining unified trust roots, global revocation epochs, and consistent proxy layers is challenging due to the differences in platform credentialminting and policy mechanisms.
11
Target API Limitations. Not all infrastructure APIs support granular parameter scoping. For example, some cloud APIs allow scoping by resource tags but do not permit scoping the specific JSON payload parameters. In these cases, the deployment must use proxy-based parameter validation to make Scopeable(C, P latf orm) true, which increases complexity and introduces a potential point of failure.
Related Work
SEB bridges ideas from capability systems, reference monitors, privileged access management, workload identity, policyas-code, and safety-critical shields, adapting them to the unique requirements of agentic control planes. 11.1
Broker Availability as a Critical Dependency. Since the broker acts as the mandatory mutation gatekeeper, any outage of the broker blocks all agent mutations, representing a single point of failure (SPoF). Maintaining high availability (HA) with multi-AZ replication, database failover, and rate limiting is required, adding substantial infrastructure overhead.
Reference Monitors and Complete Mediation
Reference monitors mediate all access requests to protected resources, enforcing properties such as complete mediation, tamper-proofing, and verifiability [2, 3]. • What SEB borrows: SEB adopts the structural design of a classical reference monitor, interposing between the client (the agent wrapper) and the resource (the target infrastructure APIs).
Operational Complexity. Transitioning legacy environments to a zero-standing-privilege posture is operationally complex. It requires configuring and maintaining Service Control Policies (SCPs), IAM permission boundaries, validating admission webhooks, and reverse proxy paths across all active mutation vectors.
• What SEB adds: Traditional reference monitors operate at the operating system or kernel level (mediating system calls). SEB implements complete mediation at the cloud control-plane and API layers. It achieves this by enforcing a zero-standing-privilege network topology where all mutation paths reject non-broker credentials, and by binding execution to dynamic admission certificates rather than static ACLs.
Revocation Consistency vs. Load. Polling the global revocation epoch at a short interval (e.g., 5 seconds) minimizes the vulnerability window for revoked certificates. However, in large deployments with thousands of broker instances, frequent polling generates significant read load on the central revocation service, requiring caching strategies that introduce consistency delays.
11.2 Privileged Access Management and Zero Standing Privilege Zero Standing Privilege (ZSP) and Just-in-Time (JIT) access aim to reduce attack surfaces by issuing temporary administrative credentials only when an active task requires them [4, 5].
State-Observation Staleness. Cloud provider APIs are eventually consistent. During drift checks, the broker queries the target state; however, if the cloud control plane has not fully propagated a background change, the broker may evaluate drift based on stale observations, introducing time-ofcheck to time-of-use (TOCTOU) windows.
• What SEB borrows: SEB builds on the ZSP philosophy, denying agents standing write credentials and issuing short-lived, transient credentials. • What SEB adds: Traditional PAM systems are humancentric, validating developer identities, MFA tokens, or approval tickets to open a time-bounded session. SEB automates this for non-deterministic agents, mapping credential scope directly to a cryptographically signed *action contract* (C) rather than a principal’s identity. Credential authority is bound to a single-use transaction.
Semantic Safety Remains External. The broker is an execution-time enforcement boundary. It guarantees that the request matches the certificate, but it cannot verify if the certificate’s contract itself is semantically safe. If SAB (or SQA) admits a faulty or malicious proposal due to validator compromise, SEB will execute it. 17
11.3 Cloud Control-Plane Authorization and Workload Identity
into ephemeral IAM policies and validating them against validity windows, revocation epochs, and database transaction logs.
Workload identity systems (e.g., SPIFFE/SPIRE) issue cryptographic service identities to workloads [6, 7], while cloud platforms provide mechanisms like AWS STS session policies and Kubernetes projected tokens to down-scope permissions [8, 9].
11.6
Software supply-chain frameworks (e.g., in-toto, SLSA) bind build steps and materials to cryptographic attestations of provenance [17, 18]. Replicated consensus protocols (e.g., Paxos, Raft) are used to order events durably [19, 20].
• What SEB borrows: SEB utilizes workload identity for broker service authentication and leverages STS/TokenRequest APIs to generate down-scoped credentials. • What SEB adds: Workload identity verifies *who* is running but does not evaluate *what* the workload intends to do or whether it is safe. SEB acts as a controller layer on top of these identity substrates. It dynamically translates the signed, high-level assurance contract C from SAB into corresponding JSON-formatted session policies, session tags, and projected tokens, while interposing a validation proxy to enforce parameter-level constraints that the underlying cloud IAM cannot natively express. 11.4
• What SEB borrows: SEB borrows the concept of cryptographically signed build/execution provenance and utilizes append-only log structures. • What SEB adds: Supply-chain systems verify provenance post-hoc (after the build completes). SEB evaluates provenance pre-execution (asserting that a mutation matches the SAB certificate) and binds the post-execution outcome. By signing both D ECISION R ECORDs and O UTCOME R ECORDs, SEB builds an active, tamper-proof runtime audit trail that connects the agent’s intent to the final system state.
Policy-as-Code and Admission Control
Policy decision engines such as Open Policy Agent (OPA), Gatekeeper, Kyverno, and Cedar decouple authorization logic from target application platforms [10–13].
12
• What SEB borrows: SEB leverages the declarative payload inspection concepts popularized by policy-as-code engines.
Conclusion
As non-deterministic agentic control planes assume greater operational authority over production systems, traditional authorization models based on static identity privileges become untenable. This paper introduced the Sovereign Execution Broker (SEB), a runtime enforcement boundary that addresses the gap between proposal admission and runtime infrastructure mutation. By separating proposal, admission, and execution, SEB removes standing mutation credentials from autonomous agents when target APIs are configured to reject non-broker identities, and turns certified authority into short-lived, revocable, and auditable runtime capabilities. We presented the SEB execution model, formalized its certificate, nonce, record, and scopeability semantics, and detailed its scoped identity and fail-closed behaviors. We implemented a Go-based prototype of SEB and evaluated its performance on AWS and Kubernetes. Our evaluation shows that SEB adds manageable latency overheads of approximately 28 ms for Kubernetes mutations and 195 ms for AWS mutations, dominated by cloud API calls and credential minting, scales to hundreds of requests per second, and successfully rejects stale, replayed, or uncertified requests under injected faults. SAB certifies proposal authority, but SEB is the mandatory runtime enforcement boundary that turns certificates into fresh, scoped, revocable mutation authority.
• What SEB adds: Policy-as-code engines are stateless Policy Decision Points (PDPs) that evaluate static rules against incoming requests. They do not handle credential-minting custody, database nonce reservations, or target-state drift checks. SEB is a stateful Policy Enforcement Point (PEP) and reference monitor that integrates policy validation with replay protection, cache checks, and signed ledger logging. 11.5
Supply-Chain Attestations and Provenance
Runtime Enforcement for Safety-Critical Systems
Safety shields and Simplex-style architectures interpose a safety controller to override or block unsafe commands from a primary controller in physical systems [14–16]. • What SEB borrows: SEB borrows the shield concept, interposing a validator to ensure commands satisfy predefined safety boundaries. • What SEB adds: Simplex shields focus on continuous reactive feedback loops in physical environments (e.g., flight controls). SEB extends this to discrete cloud infrastructure mutations, translating abstract safety boundaries 18
References
[16] Mohammed Alshiekh, Roderick Bloem, Rüdiger Ehlers, Bettina Könighofer, Scott Niekum, and Ufuk Topcu. Safe reinforcement learning via shielding. In Proceedings of the AAAI Conference on Artificial Intelligence, pages 2669–2678, 2018.
[1] Jun He and Deying Yu. Sovereign assurance boundary: Certificate-bound admission for agentic infrastructure. arXiv preprint arXiv:2606.11632, 2026. [2] James P. Anderson. Computer security technology planning study. Technical report, Electronic Systems Division, Air Force Systems Command, 1972.
Torres-Arias, Hammad Afzali, Tris[17] Santiago hank Karthik Kuppusamy, Reza Curtmola, and Justin Cappos. in-toto: Providing farm-to-table guarantees for bits and bytes. In Proceedings of the USENIX Security Symposium, 2019.
[3] Fred B. Schneider. Enforceable security policies. ACM Transactions on Information and System Security, 3(1):30–50, 2000.
[18] SLSA Project. SLSA: Supply-chain levels for software artifacts. SLSA documentation, 2026. Accessed 202606-05.
[4] 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.
[19] Leslie Lamport. The part-time parliament. ACM Transactions on Computer Systems (TOCS), 16(2):133–169, 1998.
[5] Amazon Web Services. IAM Roles Anywhere. AWS documentation, 2026. Accessed 2026-06-05.
[20] 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.
[6] SPIFFE Project. SPIFFE standards. SPIFFE documentation, 2026. Accessed 2026-06-05. [7] SPIRE Project. SPIRE: The SPIFFE runtime environment. SPIRE documentation, 2026. Accessed 2026-0605. [8] Amazon Web Services. AWS Identity and Access Management (IAM) user guide. AWS documentation, 2026. Accessed 2026-06-05. [9] Amazon Web Services. Session policies for AWS STS. AWS documentation, 2026. Accessed 2026-06-05. [10] Open Policy Agent. Policy language. Open Policy Agent documentation, 2026. Accessed 2026-06-05. [11] Open Policy Agent Gatekeeper Project. Gatekeeper: Policy controller for Kubernetes. Gatekeeper documentation, 2026. Accessed 2026-06-05. [12] Kyverno Project. Kyverno documentation. Kyverno documentation, 2026. Accessed 2026-06-05. [13] Cedar Policy Language Project. Cedar policy language. Cedar documentation, 2026. Accessed 2026-06-05. [14] Lui Sha. Using simplicity to control complexity. IEEE Software, 18(4):20–28, 2001. [15] 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. 19