pith. sign in

arxiv: 2606.20520 · v2 · pith:VCEXGANAnew · submitted 2026-06-18 · 💻 cs.CR · cs.AI· cs.DC· cs.LG

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

Jun He , Deying Yu This is my paper

Pith reviewed 2026-06-26 16:51 UTC · model grok-4.3

classification 💻 cs.CR cs.AIcs.DCcs.LG
keywords sovereign execution brokercertificate-bound authorityagentic control planesruntime enforcement boundaryscoped execution identityrevocation epochsauditable runtime capabilitycloud mutation control
0
0 comments X

The pith

The Sovereign Execution Broker converts certified agent proposals into short-lived, revocable, auditable execution capabilities by minting scoped identities after verification.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper introduces the Sovereign Execution Broker as a runtime enforcement boundary that sits between autonomous agent proposals and production infrastructure mutations. SEB accepts certificates from the Sovereign Assurance Boundary, checks that the mutation request matches the certified contract, validates time windows and revocation status, then mints a scoped identity to perform the actual API call while logging the outcome. This matters to a sympathetic reader because it supplies a mandatory enforcement point that existing identity authorization or action certification layers lack, turning authority into a transient capability rather than a persistent grant. The entire model rests on the configuration that production APIs accept mutations only from the broker's identities.

Core claim

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.

What carries the argument

The Sovereign Execution Broker (SEB), the runtime enforcement boundary that verifies certificates against execution contracts and mints scoped identities for API invocation.

If this is right

  • Separation of proposal, admission, and execution phases allows independent revocation and audit trails for each agent action.
  • Scoped identities limit the duration and scope of any granted mutation authority.
  • Replay-verification predicates and drift checks enable post-execution detection of policy violations or state changes.
  • Bypass-prevention patterns require that all production APIs are locked to the broker identity.
  • The model defines explicit failure behavior under revocation, drift, or certificate expiry.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same boundary pattern could apply to any control plane where non-deterministic processes must affect deterministic infrastructure without holding long-lived credentials.
  • Adoption would require corresponding changes in how API gateways and cloud providers expose identity restrictions.
  • Measuring revocation propagation latency across multi-region clusters would provide a direct test of the auditable capability claim.
  • The approach aligns with zero-trust principles by making every mutation require fresh certificate validation at execution time.

Load-bearing premise

Production mutation APIs must be configured to reject every identity except the scoped execution identity minted by SEB.

What would settle it

Demonstration that an infrastructure API accepts and executes a mutation from any identity other than the current SEB-minted scoped identity, or that a revoked certificate still permits successful mutation.

Figures

Figures reproduced from arXiv: 2606.20520 by Deying Yu, Jun He.

Figure 1
Figure 1. Figure 1: OpenKedge pipeline from agent proposal to runtime enforcement. In the intended deployment, the Sovereign Exe￾cution 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 enforce￾ment gap between certified autonomous pr… view at source ↗
Figure 2
Figure 2. Figure 2: Broker verification pipeline. The request [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Scoped identity binding. The broker extracts the [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Revocation-before-execution timeline. Between ad [PITH_FULL_IMAGE:figures/full_fig_p009_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: System deployment architecture of the Sovereign Execution Broker. The Go-based service verifies certificates, interacts [PITH_FULL_IMAGE:figures/full_fig_p010_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Throughput scalability of the SEB prototype ser￾vice. 8.9 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 priv￾ileges, and crypt… view at source ↗
read the original abstract

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.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The paper introduces the Sovereign Execution Broker (SEB) as a runtime enforcement boundary for certificate-bound agentic infrastructure. SEB consumes certificates from the Sovereign Assurance Boundary (SAB), verifies that requested mutations match certified execution contracts, checks validity windows, policy epochs, revocation epochs, and live-state drift, mints scoped execution identities, invokes infrastructure APIs, and records signed decision and outcome records. By separating proposal, admission, and execution, SEB is claimed to convert certified authority into short-lived, revocable, auditable runtime capabilities, provided that production mutation APIs reject non-broker identities. The manuscript presents the execution model, certificate and replay-verification predicates, scoped identity semantics, bypass-prevention deployment patterns, failure behavior, a prototype implementation, and an evaluation on AWS and Kubernetes clusters measuring latency overheads, revocation propagation, drift detection, and security under fault injection.

Significance. If the enforcement model holds under the stated prerequisite, SEB would address a meaningful gap between existing identity-based access control and assurance layers by inserting a mandatory, auditable execution boundary for non-deterministic agent workflows in cloud and deployment settings. The provision of a concrete prototype with empirical measurements on real platforms (AWS, Kubernetes) and fault-injection testing is a positive aspect that grounds the claims in observable behavior rather than purely abstract design.

major comments (2)
  1. [Abstract] Abstract: The central security claim—that SEB provides short-lived, revocable, auditable runtime capabilities—explicitly rests on the external prerequisite that 'production mutation APIs reject non-broker identities.' The manuscript supplies deployment patterns and bypass-prevention guidance but no intrinsic mechanism, invariant, or verification procedure that would guarantee or detect violations of this rejection property under API updates, configuration drift, or multi-tenant operation. Because SEB itself performs no enforcement on the mutation surfaces, the verification predicates, revocation checks, and replay protection become irrelevant if the prerequisite fails.
  2. [Evaluation section] Evaluation (prototype on AWS and Kubernetes): The reported security results under fault injection and the measurements of revocation propagation and drift detection are conditioned on the same external configuration assumption. Without additional experiments or analysis showing behavior when non-broker identities can reach the mutation APIs, the evaluation does not establish that the runtime capability guarantee survives realistic deployment deviations.
minor comments (1)
  1. [Abstract / Introduction] The abstract and introduction use several compound terms (e.g., 'certificate-bound authority,' 'scoped execution identity') without an early glossary or reference to their formal definitions later in the model section; this reduces readability for readers outside the immediate sub-area.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive comments on the dependency of SEB's security claims on the stated deployment prerequisite. We address each major comment below and will incorporate clarifications to make the assumptions and scope more explicit.

read point-by-point responses

  1. Referee: [Abstract] Abstract: The central security claim—that SEB provides short-lived, revocable, auditable runtime capabilities—explicitly rests on the external prerequisite that 'production mutation APIs reject non-broker identities.' The manuscript supplies deployment patterns and bypass-prevention guidance but no intrinsic mechanism, invariant, or verification procedure that would guarantee or detect violations of this rejection property under API updates, configuration drift, or multi-tenant operation. Because SEB itself performs no enforcement on the mutation surfaces, the verification predicates, revocation checks, and replay protection become irrelevant if the prerequisite fails.

    Authors: We agree that the security model is conditional on production mutation APIs rejecting non-broker identities, as explicitly noted in the abstract and deployment sections. SEB is positioned as an execution-time enforcement boundary that relies on this external configuration, analogous to how many control-plane systems depend on correct API server policies. The manuscript already describes bypass-prevention patterns, but we acknowledge the lack of an intrinsic detection mechanism inside SEB for configuration violations. We will revise the abstract, threat model, and discussion sections to more prominently state the assumption, its implications, and guidance for verifying the prerequisite in multi-tenant settings. revision: partial

  2. Referee: [Evaluation section] Evaluation (prototype on AWS and Kubernetes): The reported security results under fault injection and the measurements of revocation propagation and drift detection are conditioned on the same external configuration assumption. Without additional experiments or analysis showing behavior when non-broker identities can reach the mutation APIs, the evaluation does not establish that the runtime capability guarantee survives realistic deployment deviations.

    Authors: The evaluation measures SEB behavior (latency, revocation, drift detection, and fault injection) under the prerequisite that mutation APIs accept only broker identities. We concur that the results do not include cases where the prerequisite is violated, as such scenarios lie outside the defined model. We will add explicit analysis in the evaluation discussion noting that the reported metrics assume correct deployment and that violation of the prerequisite would render the broker ineffective. No new experiments simulating direct API access by non-broker identities will be added, as they would require altering the underlying infrastructure APIs. revision: partial

Circularity Check

0 steps flagged

No circularity; design is a new component with explicitly external prerequisite

full rationale

The paper presents SEB as a novel runtime enforcement boundary that consumes certificates from SAB, performs verification, mints identities, and invokes APIs, with the core guarantee stated as conditional on an external configuration prerequisite (production mutation APIs rejecting non-broker identities). No equations, fitted parameters, predictions, or derivation chain appear in the provided text. No self-citations are invoked to justify uniqueness or load-bearing premises, and the architecture is evaluated via prototype measurements rather than reduced to prior results by construction. The design is therefore self-contained as an engineering proposal.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 1 invented entities

The design rests on standard cryptographic and systems assumptions plus the requirement that external APIs enforce broker-only access; no free parameters or invented physical entities are introduced.

axioms (2)
  • domain assumption Cryptographic certificates can be issued, verified, and revoked reliably by the Sovereign Assurance Boundary.
    Invoked when SEB consumes certificates and checks validity windows and revocation epochs.
  • domain assumption Production mutation APIs can be configured to accept only identities minted by SEB.
    Explicitly stated as a prerequisite for the enforcement model to function.
invented entities (1)
  • Sovereign Execution Broker (SEB) no independent evidence
    purpose: Runtime enforcement boundary that verifies certificate-bound mutations before execution.
    New component introduced by the paper; no independent evidence outside the design itself.

pith-pipeline@v0.9.1-grok · 5747 in / 1365 out tokens · 21029 ms · 2026-06-26T16:51:47.489174+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. Governing Actions, Not Agents: Institutional Attestation as a Governance Model for Autonomous AI Systems

    cs.AI 2026-06 unverdicted novelty 5.0

    The paper formalizes a computational governance model where AI agents retain planning autonomy but require cryptographically bound, independently attested preconditions for executing high-risk actions, supported by ta...

Reference graph

Works this paper leans on

20 extracted references · 1 linked inside Pith · cited by 1 Pith paper

  1. [1]

    Sovereign assurance boundary: Certificate-bound admission for agentic infrastructure

    Jun He and Deying Yu. Sovereign assurance boundary: Certificate-bound admission for agentic infrastructure. arXiv preprint arXiv:2606.11632, 2026

    Pith/arXiv arXiv 2026

  2. [2]

    Anderson

    James P. Anderson. Computer security technology plan- ning study. Technical report, Electronic Systems Divi- sion, Air Force Systems Command, 1972

    1972

  3. [3]

    Schneider

    Fred B. Schneider. Enforceable security policies. ACM Transactions on Information and System Security, 3(1):30–50, 2000

    2000

  4. [4]

    Zero trust architecture

    Scott Rose, Oliver Borchert, Stu Mitchell, and Sean Con- nelly. Zero trust architecture. Technical Report Special Publication 800-207, National Institute of Standards and Technology (NIST), 2020

    2020

  5. [5]

    IAM Roles Anywhere

    Amazon Web Services. IAM Roles Anywhere. AWS documentation, 2026. Accessed 2026-06-05

    2026

  6. [6]

    SPIFFE standards

    SPIFFE Project. SPIFFE standards. SPIFFE documen- tation, 2026. Accessed 2026-06-05

    2026

  7. [7]

    SPIRE: The SPIFFE runtime environ- ment

    SPIRE Project. SPIRE: The SPIFFE runtime environ- ment. SPIRE documentation, 2026. Accessed 2026-06- 05

    2026

  8. [8]

    AWS Identity and Access Man- agement (IAM) user guide

    Amazon Web Services. AWS Identity and Access Man- agement (IAM) user guide. AWS documentation, 2026. Accessed 2026-06-05

    2026

  9. [9]

    Session policies for AWS STS

    Amazon Web Services. Session policies for AWS STS. AWS documentation, 2026. Accessed 2026-06-05

    2026

  10. [10]

    Policy language

    Open Policy Agent. Policy language. Open Policy Agent documentation, 2026. Accessed 2026-06-05

    2026

  11. [11]

    Gatekeeper: Policy controller for Kubernetes

    Open Policy Agent Gatekeeper Project. Gatekeeper: Policy controller for Kubernetes. Gatekeeper documen- tation, 2026. Accessed 2026-06-05

    2026

  12. [12]

    Kyverno documentation

    Kyverno Project. Kyverno documentation. Kyverno documentation, 2026. Accessed 2026-06-05

    2026

  13. [13]

    Cedar policy language

    Cedar Policy Language Project. Cedar policy language. Cedar documentation, 2026. Accessed 2026-06-05

    2026

  14. [14]

    Using simplicity to control complexity.IEEE Software, 18(4):20–28, 2001

    Lui Sha. Using simplicity to control complexity.IEEE Software, 18(4):20–28, 2001

    2001

  15. [15]

    Shield synthesis: Runtime enforcement for reactive systems

    Roderick Bloem, Bettina Könighofer, Robert Könighofer, and Chao Wang. Shield synthesis: Runtime enforcement for reactive systems. InPro- ceedings of the International Conference on Tools and Algorithms for the Construction and Analysis of Systems (TACAS), pages 533–548, 2015

    2015

  16. [16]

    Safe reinforcement learning via shielding

    Mohammed Alshiekh, Roderick Bloem, Rüdiger Ehlers, Bettina Könighofer, Scott Niekum, and Ufuk Topcu. Safe reinforcement learning via shielding. InProceed- ings of the AAAI Conference on Artificial Intelligence, pages 2669–2678, 2018

    2018

  17. [17]

    in-toto: Providing farm-to-table guarantees for bits and bytes

    Santiago Torres-Arias, Hammad Afzali, Tris- hank Karthik Kuppusamy, Reza Curtmola, and Justin Cappos. in-toto: Providing farm-to-table guarantees for bits and bytes. InProceedings of the USENIX Security Symposium, 2019

    2019

  18. [18]

    SLSA: Supply-chain levels for software artifacts

    SLSA Project. SLSA: Supply-chain levels for software artifacts. SLSA documentation, 2026. Accessed 2026- 06-05

    2026

  19. [19]

    The part-time parliament.ACM Trans- actions on Computer Systems (TOCS), 16(2):133–169, 1998

    Leslie Lamport. The part-time parliament.ACM Trans- actions on Computer Systems (TOCS), 16(2):133–169, 1998

    1998

  20. [20]

    In search of an understandable consensus algorithm

    Diego Ongaro and John Ousterhout. In search of an understandable consensus algorithm. InProceedings of the USENIX Annual Technical Conference (ATC), pages 305–320, 2014. 19

    2014