Sovereign Execution Brokers: Enforcing Certificate-Bound Authority in Agentic Control Planes

Source: arXiv:2606.20520 · Published 2026-06-18 · By Jun He, Deying Yu

TL;DR

This paper addresses a critical gap in autonomous agent infrastructure control: the inability of existing access control and admission certificate mechanisms to enforce guaranteed, certificate-bound authority at the moment of infrastructure mutation. Current systems either authorize identities or certify proposals but do not mandate that only authorized, certified actions can mutate production resources. The authors propose the Sovereign Execution Broker (SEB), a runtime enforcement boundary that strictly enforces certificate-bound authority. SEB validates signed certificates from a Sovereign Assurance Boundary (SAB), ensuring requested mutations exactly match certified contracts, are valid in terms of time windows, policy epochs, revocation status, and live system state, before minting scoped and ephemeral credentials to execute the action. SEB also logs cryptographically signed decision and outcome records to enable auditing and replay protection.

The key novelty is the separation of proposal, admission, and execution phases to confine standing mutation credentials solely within the broker. This prevents autonomous agents from possessing long-lived credentials that could be abused. A prototype SEB implementation on AWS and Kubernetes demonstrates the feasibility of the execution model, with latency, revocation propagation, and fault tolerance measured in real clouds. The evaluation confirms that SEB enforces revocation-before-execution, live drift detection, and scoped identity constraints with acceptable overheads. This work thus elevates the trustworthiness of agentic control planes by mandating runtime enforcement of certified authority tightly bound to validated certificates.

Key findings

• SEB prototype latency median (p50) execution overhead is in the low milliseconds range across AWS and Kubernetes environments, with 95th and 99th percentile latencies reported (exact numbers not specified in truncated text).
• Revocation epoch propagation enables immediate rejection of certificates signed under stale epochs, effectively enforcing revocation-before-execution (Section 6.3, Fig 4 timeline).
• Live drift detection via a policy-defined drift tolerance ϵC successfully blocks execution requests if the target infrastructure state diverges beyond acceptable limits compared to admitted evidence state (Section 6.2).
• Nonce reservation prevents certificate replay attacks by atomically reserving (cid, nonce) pairs before minting credentials or executing mutations — duplicate requests are rejected even if the first attempt failed after reservation (Section 4.3, Eq 8).
• Scoped execution identities minted at execution time constrain permissions by action, resource, parameters, time, policy version, and revocation epoch, reducing standing privilege risk (Section 5, Table 3).
• SEB implements a fail-closed policy: if the Revocation Service or live state monitoring is unreachable, SEB rejects mutation requests rather than permitting blind execution (Section 6.4).
• SEB logs every verification decision and mutation outcome with cryptographic bindings to original SAB certificates, enabling strong post-hoc auditability and accountability (Section 4.4).
• Implementation includes adapters for AWS STS and Kubernetes TokenRequest, along with mandatory mutation-path enforcement through IAM policies and Kubernetes admission webhooks to prevent broker bypass (Section 5.2).

Threat model

The adversary is an attacker capable of compromising the autonomous agent runtime, injecting malicious prompts, intercepting network traffic, or attempting to exploit asynchronous gaps between proposal admission and execution. They may try to bypass certificate verification by using standing credentials to call mutation APIs directly, replay stale or revoked admission certificates, submit mutation requests mismatched to their certificates, exploit time-of-check to time-of-use (TOCTOU) state drift to execute unsafe actions, or attempt to abuse overbroad credentials minted by the broker. However, the adversary cannot compromise the SEB execution environment, the SAB private keys, the global revocation epoch service, or the cloud provider's identity provider and policy enforcement mechanisms configured to enforce mutation path restrictions.

Methodology — deep read

1. Threat Model & Assumptions: The threat model assumes an adversary can compromise the autonomous agent runtime or its prompting, attempt to bypass admission controls by using standing cloud API credentials, replay stale certificates, submit mismatched requests, or exploit state drift between admission and execution. Trusted components include the SEB environment, SAB keys, revocation epoch service, identity provider, target platform IAM and admission policies, and the append-only ledger. Agents and wrappers hold no standing mutation credentials, and mutation is only authorized if mediated by the broker.

2. Data & Provenance: The system processes SAB-issued certificates encapsulating proposed mutation contracts, live target infrastructure state snapshots, and policy/epoch metadata. The prototype collects evidence state from cloud APIs and orchestrators to evaluate drift.

3. Architecture/Algorithm: SEB exposes the Execute(Ω, req, St, Platform) interface that consumes an SAB certificate Ω, mutation request req, live state St, and platform descriptor. It runs a verification pipeline applying chained predicates: cryptographic signature check (Φsig), strict request-certificate matching (Φmatch), validity window check (Φtime), policy epoch consistency (Φpolicy), revocation epoch freshness (Φrev), live drift metric within tolerance (Φdrift), replay prevention via nonce reservation (Φreplay), and scopeability of the mutation request on the target platform (Scopeable). If all predicates hold, SEB mints a scoped execution identity IDexec with finely constrained privileges, executes the mutation via platform-specific adapters (e.g., AWS STS AssumeRole or Kubernetes TokenRequest), then records signed decision and outcome records.

4. Training & Runtime Details: Not applicable.

5. Evaluation Protocol: The prototype was deployed on AWS EKS clusters and AWS cloud environments. Performance was measured across p50, p95, and p99 latency percentiles for the verification pipeline and execution. Revocation propagation delays were tested to ensure stale certificates are rejected promptly. Fault injection simulated partition and crash recovery. Drift detection was validated by injecting controlled changes in live infrastructure state.

6. Reproducibility: The paper details a 4,200-line Go codebase organized into verification, revocation polling, ledger storage, adapter, and proxy components. Cryptographic operations use Go's standard ed25519 library with deterministic canonical JSON parsing of certificates. Runtime uses PostgreSQL for ledger storage and is deployed with 3 replicas for high availability. No public code release indicated, but the architecture and protocol are described for potential replication.

Example Walkthrough: Consider an agent proposal to add a security group ingress rule. SAB validates this and issues Ωfw. Before execution, the subnet is decommissioned. SEB receives the execution request with Ωfw and checks Φdrift against the current subnet state, detecting the drift beyond tolerance. SEB rejects execution and logs a DecisionRecord. The agent must re-submit a new proposal to SAB for an updated action. This ensures no stale or unsafe certificate execution occurs despite asynchronous delays and state changes.

Technical innovations

• Introduction of the Sovereign Execution Broker (SEB) as a mandatory runtime enforcement boundary that enforces certificate-bound authority at mutation time, closing the gap between admission certification and actual execution.
• Formal certificate verification predicate combining cryptographic signature, contract matching, temporal validity, policy and revocation epochs, live-state drift tolerance, replay prevention, and scopeability into a unified Execute() interface.
• Scoped execution identity model that mints ephemeral, least-privilege credentials strictly bound to the certified contract, target resource, validity window, and revocation epoch, preventing standing credential abuse by agents.
• Deployment pattern enforcing that mutation APIs reject all non-broker mutation identities and requiring mandatory mutation paths through the broker, enforced via IAM permission boundaries and admission webhooks on cloud and Kubernetes platforms.

Baselines vs proposed

• IAM-only authorization: no runtime enforcement on certificate freshness or drift; allowing agent standing credentials with unlimited mutation capability vs SEB-enforced scoped credentials with live drift and revocation checks.
• SAB admission without SEB enforcement: certificates act solely as audit logs and can be bypassed vs SEB enforcing verification predicates prior to mutation execution.
• SEB fail-closed enforcement on unavailable revocation service: rejects execution vs naive fallback allowing mutation, improving security at cost of availability.

Limitations

• Prototype evaluation metrics and results are summarized but exact latency numbers, throughput, and scalability limits are not comprehensively reported in the truncated text.
• The approach assumes reliable and timely access to live state evidence and revocation epoch services; eventual consistency or delays in these services may cause false rejections or hinder availability.
• The security properties rely heavily on correctly configured deployment patterns—specifically, mandatory mutation path enforcement and denial of standing credentials elsewhere; misconfiguration can lead to bypass.
• SEB depends on cloud and orchestration platform capabilities for enforcing scoped permissions and admission controls; platforms lacking rich policy expression may require additional proxy layers, increasing complexity.
• The work does not explicitly evaluate adversarial attempts to compromise the broker environment or its cryptographic keys, assuming these components are fully trusted.
• Crash recovery and idempotency mechanisms rely on durable ledger state and evidence from target platforms, which could be lacking or inconsistent in real deployments.

Open questions / follow-ons

• How to robustly handle scenarios with eventual consistency in live state evidence feeds, minimizing false rejections due to temporary stale or delayed data?
• What are the performance and scalability trade-offs when integrating SEB into very large-scale, highly dynamic agentic control environments with frequent mutations?
• Can the SEB architecture be extended to support decentralized or federated deployment models across multi-cloud or hybrid infrastructure?
• How can emergency break-glass or human override paths be securely integrated without weakening the autonomous broker enforcement guarantees?

Why it matters for bot defense

This work is highly relevant to bot-defense engineers designing secure autonomous orchestration and agentic control systems where untrusted agents interact with cloud infrastructure. SEB’s enforced certificate-bound execution model tightens the security boundary by ensuring that agents cannot act beyond cryptographically admitted authority. It prevents risks such as agent hijacking or ‘hallucination’ induced destructive mutations common in LLM-powered automation. For CAPTCHA and bot-detection practitioners, this approach exemplifies robust runtime enforcement of short-lived, constrained capabilities rather than relying solely on identity or static credential checks, which can be bypassed or forged. Adopting similar certificate-to-execution binding and replay resistance principles strengthens defense-in-depth postures for automated workflows interacting with sensitive backend APIs. The mechanisms to detect state drifts and epoch-based revocation can also help defend against replay or stale-credential attacks in other automated user or bot interaction systems.

Cite

@article{arxiv2606_20520,
  title={ Sovereign Execution Brokers: Enforcing Certificate-Bound Authority in Agentic Control Planes },
  author={ Jun He and Deying Yu },
  journal={arXiv preprint arXiv:2606.20520},
  year={ 2026 },
  url={https://arxiv.org/abs/2606.20520}
}

Read the full paper

• arXiv:2606.20520 (abstract)
• arXiv:2606.20520 (PDF)