EBL-Core pins agent actions to verifiable execution grants

Problem

The paper studies the semantic gap between an AI agent proposing an externally consequential action and the point at which that proposed action may actually acquire authority to change external state. Existing components—policies, monitors, provenance and guardrails—lack a standard contract that binds a single, canonical, fully materialised candidate action to the decision inputs, evidence, policy versions, time and a verifiable decision path at the moment authority is granted and used. This gap matters for high-risk actions such as financial transfers, infrastructure changes, software deployments, data disclosures and physical actuation, because decisions can become stale, candidates can be mutated after adjudication, evidence can expire or conflict, and alternative effect-producing paths may bypass decision logic.

Approach

The authors specify EBL-Core, a conformance profile for an execution boundary that governs release and redemption of action-scoped execution authority. EBL-Core requires: a trusted intent object; one canonical, fully materialised candidate; a versioned Root Policy and an Operational Policy with non-weakening semantics; separately derived evidence obligations and typed evidence classified under an evidence-resolution profile; explicit decision-relevant context and time; and a verifiable Decision Derivation. These elements are bound into an Execution Release Contract (ERC) that records the adjudication inputs and derivation but is not itself authority. A verified ALLOW ERC may support separate Grant Issuance; the resulting grant begins in ISSUED and can move to CONSUMED, EXPIRED or REVOKED. Redemption must revalidate committed inputs and linearise validation, grant-consumption and the protected effect. The paper provides a minimal reference artefact instantiating a financial-transfer profile, machine-readable schemas, a reference adjudicator, an independent verifier with Semantic Replay, canonicalisation and SHA-256 commitments, and an in-memory linearisable grant store used as the linearisation point for the protected test effect.

Key Findings

• EBL-Core defines a testable execution-release contract that binds intent, candidate, root and operational policy versions, obligation sets, evidence, context, time and a Decision Derivation through an ERC without making the ERC itself an authority-bearing token.
• The reference artefact executed a retained validation in which 34 static mutation vectors and 15 lifecycle checks matched specified outcomes, showing the profile is implementable for the included subset.
• Concurrency and lifecycle results in the artefact: across 100 trials where 32 concurrent Redemption attempts targeted a grant, each trial produced exactly one successful Redemption and one protected test effect; 100 Revoke–Redeem races produced valid terminal outcomes, demonstrating the single-use linearisable semantics.
• Semantic requirements include deterministic, input-closed adjudication, root-policy dominance (Operational Policy may add but not weaken root obligations), evidence must be classified VALID to discharge positive obligations, and explicit equality of committed versions at Redemption.

Limitations

EBL-Core does not claim human-intent correctness, evidence truth, complete mediation across all effect paths, global non-bypassability, faithful Effector behaviour, production readiness, mechanised proof of correctness, or robustness against compromise of trusted roles. The reference artefact covers a single financial-transfer profile, shares canonicalisation primitives between adjudicator and verifier, and is not an independent cross-implementation validation. Performance, broad domain coverage and deployment-level assurance remain future work.

Implications

From an offensive-security viewpoint, the profile highlights concrete attack surfaces an adversary could exploit if deployment assumptions fail: constructing a candidate inconsistent with the intent, substituting or mutating a candidate after adjudication, omitting or presenting malformed/expired/conflicting evidence, causing Operational Policy to omit root obligations, replaying ERCs or grants, racing concurrent Redemptions, exploiting state transitions between validation and effect, presenting ERCs under different policy or profile versions, or forcing disagreement between adjudicator and verifier. Implementers should assume these attack vectors exist unless the deployment enforces complete mediation, exclusive authority over effectors, protected keys and linearisable state transitions.