Technical Summary: Sovereign Execution Brokers

Problem Statement

As autonomous agents powered by Large Language Models (LLMs) transition from passive analytical tools to active operational planners, they are increasingly integrated into production infrastructure workflows (e.g., auto-scaling, deploying containers, managing security groups). However, granting these non-deterministic reasoning processes direct, standing access credentials creates severe security risks. A single hallucination or adversarial prompt injection could trigger unauthorized or destructive infrastructure mutations.

Existing architectures attempt to mitigate this by introducing an admission gate, such as the Sovereign Assurance Boundary (SAB), which validates proposed actions and issues a cryptographically signed certificate ($\Omega$). However, an admission certificate alone is insufficient for enforcement. Without a runtime mechanism that actively requires the certificate for execution, agents or compromised wrappers can bypass the admission gate entirely using standing credentials. Furthermore, even if the admission process is followed, the time lag between proposal admission and actual execution creates a vulnerability window where the system state may drift, or security policies may change (Time-of-Check to Time-of-Use, or TOCTOU, vulnerabilities).

Methodology: The Sovereign Execution Broker (SEB)

The paper introduces the Sovereign Execution Broker (SEB), a runtime enforcement boundary designed to bridge the gap between certified autonomous proposals and actual infrastructure mutation. The core architectural principle is the separation of proposal, admission, and execution.

Core Architecture

1. Zero Standing Privileges: In the intended deployment, no agent runtime or wrapper holds standing production mutation credentials. All autonomous mutation requests must pass through the SEB.
2. Certificate Verification Pipeline: The SEB acts as a gatekeeper that consumes an SAB certificate ($\Omega$) and an execution request ($req$). Before execution, it runs a formal verification pipeline checking:
   • Signature ($\Phi_{sig}$): Validity of the SAB signature.
   • Contract Match ($\Phi_{match}$): Ensuring the request parameters, target, and operation exactly match the certified contract $C$.
   • Validity ($\Phi_{time}$): Ensuring the request falls within the certificate's validity window.
   • Policy & Revocation ($\Phi_{policy}, \Phi_{rev}$): Verifying the certificate matches the active policy version and has not been revoked via a global epoch counter.
   • Drift Detection ($\Phi_{drift}$): Comparing the live target state ($St$) against the evidence state ($E_{admit}$) captured at admission time to detect TOCTOU changes.
   • Replay Resistance ($\Phi_{replay}$): Ensuring the certificate nonce has not been previously used.
3. Scoped Execution Identity: Upon successful verification, the SEB does not execute using its own master credentials. Instead, it acts as a token broker, minting a short-lived, down-scoped execution identity ($ID_{exec}$) bound strictly to the certified contract, target resource, and validity window.
4. Enforcement Patterns: To prevent bypass, the target infrastructure (e.g., AWS, Kubernetes) must be configured to reject all mutation requests that do not originate from the broker or broker-issued sessions. This is achieved via Service Control Policies (SCPs), IAM permission boundaries, and validating admission webhooks.
5. Auditability: Every verification decision (rejection or re-admission) and execution outcome is recorded in a signed, append-only ledger, providing cryptographic evidence linking the action to the original certificate.

Key Contributions

The paper makes four primary contributions:

1. Broker-Enforced Autonomy: It identifies the enforcement gap between certified proposals and actual mutation, defining the SEB as the runtime boundary that prevents agents from holding standing credentials.
2. Certificate-Verification Execution Model: It formalizes the broker interface $Execute(\Omega, req, St, Platform) \rightarrow D | O$, detailing the predicates for signature, contract matching, validity, policy, revocation, drift, and replay checks.
3. Scoped Identity and Revocation-Before-Execution: It introduces a least-privilege model where credentials are minted only at execution time, scoped to the contract, and subject to revocation checks immediately prior to execution.
4. Prototype Implementation and Evaluation: A Go-based prototype (approx. 4,200 lines of code) was implemented with adapters for AWS STS and Kubernetes TokenRequest, deployed as a mandatory mutation path, and evaluated under realistic workloads.

Experimental Results

The prototype was evaluated on AWS and Kubernetes clusters (Amazon EKS) to measure latency, throughput, and security under fault injection.

• Latency Overhead:
  • Kubernetes: The broker adds approximately 28.2 ms (p50) of overhead to mutation operations. The primary bottlenecks are live drift checks (42.9%) and credential minting (42.9%).
  • AWS: The overhead is higher, approximately 136.9 ms (p50), dominated by AWS STS credential minting and drift checks (DescribeSecurityGroups API calls).
  • Comparison: While Direct IAM and Audit-Only logging have near-zero overhead, they lack the security guarantees of the SEB. The SEB overhead is considered manageable for high-risk, low-frequency mutations (e.g., firewall changes, auto-scaling) but is noted as unsuitable for microsecond-scale control loops.
• Revocation Propagation: With a 5-second polling interval for the revocation epoch, the system achieves a maximum propagation delay of 5.2 seconds from epoch advancement to 100% request rejection.
• Security and Fault Tolerance:
  • In 1,000 injected test cases covering threats like broker bypass, stale certificate replay, request-certificate mismatch, and network partitions, the SEB achieved a 100% rejection rate for unauthorized or invalid requests.
  • Fail-Closed Semantics: Under network partitions or service failures, the broker defaults to rejecting requests to prevent unsafe execution.
  • Crash Recovery: The system successfully handled broker crashes using idempotency tokens to prevent duplicate mutations, ensuring state consistency.

Significance and Claims

The paper claims that the SEB provides a necessary runtime enforcement layer for agentic control planes that traditional Identity and Access Management (IAM) and policy engines cannot provide.

• Shift from Identity to Action: Unlike IAM, which authorizes who can do what, the SEB authorizes this specific, certified action under current system evidence.
• Mitigation of TOCTOU: By checking live state drift and revocation epochs immediately before execution, the SEB closes the vulnerability window between admission and mutation.
• Enforcement Theorem: The paper presents a formal proof (Theorem 1) stating that, under specific deployment assumptions (no standing credentials for agents, target APIs reject non-broker identities), an untrusted agent cannot cause a production state mutation unless it matches a valid, unexpired, unrevoked, and un-replayed certificate with an enforceable scope.

The authors conclude that while the SEB introduces latency overhead, it transforms certified authority into short-lived, revocable, and auditable runtime capabilities, making it a viable solution for securing autonomous agents in production environments where the cost of a security breach outweighs the cost of latency.