PaperlayerView exact revision on arXiv

Source-linked AI summary

From Intent to Execution Grant: An Execution-Boundary Conformance Profile for High-Risk AI Actions

Mengting Wu, Lin Wang, Yong Zhang, Jiang Deng

arXiv:2609.11596v1cs.CR

TL;DR

AI agents increasingly propose actions that can affect external systems, but existing mechanisms do not necessarily share semantic conditions for granting authority to a particular candidate. The paper defines EBL-Core and its Execution Release Contract to bind candidate, intent, policies, evidence, context, time, and derivation through release and redemption. Its bounded artifact validation matched specified outcomes and concurrency properties, while the authors limit claims about human intent, evidence truth, mediation, and deployment security.

  • Problem

    Existing authorization, runtime, provenance, and guardrail mechanisms do not necessarily impose a common semantic contract on the transition from one candidate action to execution authority.

  • Method

    EBL-Core binds one canonical, fully materialized candidate to trusted intent, versioned policies, evidence obligations and typed evidence, context, time, and a verifiable derivation through an Execution Release Contract.

  • Results

    EBL-Core specifies action binding, policy non-weakening, evidence handling, deterministic adjudication, derivation verification, and grant lifecycle behavior for its execution-release profile.

  • Takeaways & Limitations

    A verified ALLOW ERC may support separate Grant Issuance, while Redemption determines whether the resulting action-scoped authority can be exercised.

  • Takeaways & Limitations

    The bounded results do not establish human-intent correctness, evidence truth, complete mediation, production readiness, mechanized correctness, or deployment-level security.

Abstract

from arXiv · show

AI agents increasingly propose actions with external consequences, including financial transfers, infrastructure changes, software deployments, disclosures, and physical actuation. Authorization engines, policy languages, runtime monitors, provenance mechanisms, and agent guardrails provide important foundations, but do not necessarily define a common semantic contract for the final transition from a particular candidate action to execution authority. We specify EBL-Core, an execution-boundary conformance profile for deciding whether one canonical, fully materialized AI-generated candidate may receive action-scoped execution authority under explicit conditions. It binds a structured intent object, Root and Operational Policies, evidence obligations, typed evidence, context, time, and a verifiable Decision Derivation through an Execution Release Contract (ERC). An ERC is not an authority-bearing token; a verified ALLOW ERC may support a separate Execution Grant governed by Redemption-time validation. EBL-Core specifies action binding, policy non-weakening, evidence handling, deterministic adjudication, derivation verification, and grant lifecycle behavior. An accompanying reference artifact provides schemas, adjudication, separate verification and Semantic Replay, and a linearizable in-memory grant store. In the retained run, 34 static vectors and 15 lifecycle checks matched expected outcomes. Across 100 trials, 32 concurrent Redemption attempts yielded exactly one successful Redemption and protected test effect per trial; 100 Revoke-Redeem races ended in valid terminal outcomes. These bounded results demonstrate executability of the specified subset, not human-intent correctness, evidence truth, complete mediation, production readiness, mechanized correctness, or deployment-level security.

1 Introduction

AI agents can turn generated plans into externally consequential actions, creating a need for a semantic contract governing when a specific candidate may receive execution authority. EBL-Core defines that contract by binding intent, policies, evidence, context, time, derivation, and grant lifecycle at the execution boundary.

  • The Execution-Release Problem: EBL-Core addresses the missing joint contract governing the transition from one concrete AI-generated action proposal to action-scoped execution authority.The profile targets the integration boundary among authorization, evidence, provenance, runtime, and agent mechanisms.
  • The Execution-Release Problem: The execution-release contract binds a canonical, fully materialized candidate to trusted intent, Root and Operational Policies, evidence obligations, typed evidence, context, time, and a verifiable Decision Derivation.It also requires policy non-weakening, deterministic evaluation, and lifecycle conditions for resulting authority.
  • Relationship to Existing Abstractions: The profile complements rather than replaces authorization languages, proof systems, reference monitors, and runtime mechanisms by specifying the bindings they must jointly expose.The accompanying artifact validates a bounded transfer profile, while interoperability among independent implementations remains a future empirical question.
  • Scope and Deployment Boundary: A valid ALLOW decision and Execution Release Contract do not alone guarantee external execution depends on that decision or that the realized effect matches the candidate.Those stronger properties require complete mediation, correct grant handling, linearized redemption, protected components, faithful effectors, and exclusion of alternative authority paths.
  • Execution-Boundary Semantics: The candidate—not an earlier request or plan—is adjudicated, while authorized refinement remains possible only when immutable intent constraints are preserved.This binding establishes consistency with the trusted intent object but does not establish that the object captures latent human intent.
  • Contributions: The paper contributes an execution-boundary conformance model, intent-bound evidence-aware adjudication semantics, and an Execution Release Contract connecting adjudication to separate issuance and redemption.These contributions are designed to operate over heterogeneous authorization, evidence, capability, and runtime mechanisms.

2 Related Work

Related systems provide policy evaluation, capability security, proof mechanisms, runtime mediation, and agent control, but their primary abstractions do not uniformly specify one execution-release contract. EBL-Core defines that residual profile by binding the final candidate, intent, policies, evidence, derivation, grant issuance, and Redemption lifecycle.

  • 2.4 AI Agent Action Control: The profile complements existing authorization engines, proof systems, capability mechanisms, and runtime monitors by specifying which versioned facts must jointly justify an action-scoped grant and when it must be rejected or re-adjudicated.These mechanisms can serve as EBL backends; EBL-Core does not claim to introduce their underlying capabilities.
  • 2.1 Authorization Languages: Policy languages evaluate structured authorization inputs but do not uniformly require bindings among trusted intent, the exact canonical candidate, evidence obligations, policy versions, grant issuance, and Redemption.These requirements may be expressed through attributes, policies, obligations, or application logic, but their cross-component semantics depend on integration.
  • 2.2 Capability and Proof-Carrying Authorization: EBL-Core makes candidate binding, typed evidence, invalidation, execution-release certification, and Redemption-time checks mandatory within a restricted conformance profile.It does not claim greater general policy expressiveness; existing authorization logics can represent these properties.
  • 2.2 Capability and Proof-Carrying Authorization: The EBL decision derivation is an execution-specific derivation rather than a new proof-carrying primitive, and successful verification establishes only that the decision follows under declared inputs and trust assumptions.Verification does not establish that evidence premises accurately describe the external world or that the authorized effect is faithfully realized.
  • 2.3 Reference Monitor and Runtime Assurance: Reference monitors and runtime-assurance systems explain enforcement placement and structural requirements but do not determine the intent, evidence, policy-version, or action-identity obligations for AI-generated transactions.Their abstractions do not by themselves define the heterogeneous authorization and evidence semantics required at the execution boundary.
  • Scope and contribution: EBL-Core defines a common execution-release profile for the jointly specified obligations that existing mechanisms distribute across abstractions.The profile covers one canonical candidate, trusted intent, non-weakening policies, typed evidence, Decision-Derivation Verification, an ERC distinct from authority, and linearized Redemption.

3 System Model and Execution Release Contract

EBL-Core separates candidate materialization, adjudication, ERC generation, grant issuance, and redemption so one canonical action can receive authority only under bound conditions. Its contract preserves intent, policy, evidence, context, time, derivation, and single-use lifecycle constraints.

  • Adjudication: Adjudication evaluates intent, versioned policies, separately derived evidence obligations, explicit context, and explicit time, returning a decision, reason, and derivation.The operational policy may add obligations but cannot remove, weaken, rename, or reinterpret root-policy obligations.
  • Grant Lifecycle: Grant redemption validates the exact candidate and current conditions, permits one successful redemption, and changes the grant from ISSUED to CONSUMED.Validation, grant consumption, and the protected transition must be linearized with respect to decision-relevant state.
  • Candidate Action Materialization: Every decision-relevant candidate parameter must be concretely committed before adjudication; later changes require a new adjudication.Plans, partial payloads, unresolved parameters, and later-selected targets are not materialized candidates.
  • Execution Release Contract: One ERC binds exactly one canonical candidate to adjudication inputs and release conditions, but is not itself authority-bearing.A verified ALLOW ERC can support separate grant issuance; a DENY ERC cannot.
  • Evidence Obligations: Evidence classified VALID discharges obligations under declared resolution rules but does not establish the external truth of the underlying assertion.At redemption, time- and state-dependent evidence conditions must still hold; otherwise the grant is rejected or the candidate is re-adjudicated.
  • Conformance Properties: The profile requires deterministic decisions, root-policy dominance, derivation verification, single-use grants, and rejection when redemption conditions diverge from the ERC.These semantic requirements do not by themselves establish correct external execution or intended outcomes.

4 Formal Execution-Boundary Semantics

The formal semantics define canonical identity, intent-to-candidate binding, evidence obligations, and deterministic evidence resolution. They constrain authorization to fully materialized objects while explicitly separating conformance judgments from authenticity, human intent, and external truth.

  • 4.1 Semantic Domains and Canonical Identity: Canonicalization and commitments provide stable replay identity for equivalent semantic objects under one profile version.Implementations using the same profile and semantic object must derive the same canonical representation and commitment.
  • 4.1 Semantic Domains and Canonical Identity: Canonical identity establishes model-level equality, not authenticity, authorization, provenance, or external truth.The selected commitment assumption concerns computational infeasibility, not those additional properties.
  • 4.2 Intent-to-Candidate Binding Semantics: Intent binding holds only for one candidate whose execution-relevant parameters have concrete committed values.Permitted refinement may resolve authorized domains but cannot leave choices for post-adjudication selection.
  • 4.2 Intent-to-Candidate Binding Semantics: Action families and unresolved bounded actions are outside baseline EBL-Core and require an extension profile with separate identity, refinement, and redemption semantics.Binding also does not establish that an intent captures a human request or that execution achieves its declared purpose.
  • 4.3 Evidence-Obligation Semantics: Root and operational obligations are generated independently, and each obligation records its policy origin, assertion scope, admissible evidence, freshness, conflict rules, and resolution semantics.Operational policy cannot remove, weaken, replace, or reinterpret root obligations.
  • 4.3 Evidence-Obligation Semantics: Evidence status is deterministic under the identified profile, and unresolved applicable conflicts prevent an obligation from being classified VALID.The discharge predicate holds exactly when Status(q, Ev, Ctx, t) = VALID.
  • 4.3 Evidence-Obligation Semantics: The combined evidence judgments establish satisfaction of declared obligations under the profile, not the external truth of their underlying assertions.The lifecycle separates adjudication, ERC generation, grant issuance, and redemption; redemption rechecks current conditions before protected effect.

4.4 Policy-Composition Semantics

EBL-Core composes operational policy conjunctively with fixed root-policy constraints and separately treats policy-version evolution as a compatibility question. Non-weakening applies only under specified composition semantics, while root-policy changes require new adjudication.

  • 4.4 Policy-Composition Semantics: An empty operational policy permits the root-policy result without adding obligations or operational restrictions.The formal baseline sets Permit∅ and OperationalOK∅ to true and Q∅ to the empty set.
  • 4.4 Policy-Composition Semantics: Operational policy cannot modify root permission, root obligations, or their resolution semantics under the fixed-root assumptions.The non-weakening property is relative to one fixed root-policy version and does not establish that the root policy is correct or complete.
  • 4.4 Policy-Composition Semantics: Adding an operational rule conjunctively can only restrict permitted candidates under the specified obligation-union semantics.This property does not extend to arbitrary replacement, deletion, reprioritization, or reinterpretation of rules.
  • 4.4 Policy-Composition Semantics: Policy-version compatibility requires a validation procedure showing that the new policy’s allow set is contained in the old policy’s allow set for all fixed-root inputs.Version order, naming, or additional rules alone do not establish compatibility.
  • 4.4 Policy-Composition Semantics: Baseline ERC reuse requires exact operational-policy version equality, and compatibility does not preserve all old grants.A root-policy change lies outside the operational-policy relation and requires a new adjudication.

4.5 Adjudication Function

The adjudication function deterministically evaluates a complete input bundle, selects a primary failure by profile-defined precedence, and requires supplied derivations to verify against the committed inputs. It is pure with respect to external state.

  • 4.5 Adjudication Function: The positive adjudication rule returns ALLOW, OK, and an allow derivation exactly when the core predicates hold.Otherwise the profile returns a denial result through its defined failure handling.
  • 4.5 Adjudication Function: Simultaneous failures receive a deterministic primary reason from the profile’s ordered failure sequence, while the derivation may retain the full diagnostic set.INPUT_INVALID dominates semantic failures when a structurally undefined predicate occurs.
  • 4.5 Adjudication Function: A supplied decision derivation is eligible only when verification succeeds against the complete adjudication bundle, decision, and reason.Each ERC commits to the particular derivation supplied with that ERC.
  • 4.5 Adjudication Function: Equivalent closed input bundles evaluated under the same semantic profile must produce the same decision and primary reason.This determinism concerns canonical equivalence and does not require identical valid derivation encodings across implementations.
  • 4.5 Adjudication Function: Adjudication does not modify external, policy, evidence, grant, or protected system state and depends only on its declared bundle.Conforming evaluation does not consult undeclared clocks, network sources, mutable services, randomness, or hidden model inference.
  • 4.5 Adjudication Function: Resource bounds are profile conformance requirements rather than measurements or verification claims about a particular implementation.The profile specifies an input fragment and resource-bound function.

4.6 Decision-Derivation Semantics

Decision Derivation is a structured, profile-relative witness that commits an adjudication to its supported profile, inputs, policies, obligations, evidence, and admitted inference steps.

  • Decision Derivation Verification: A Decision Derivation verifies only when its profile, bundle commitments, policy versions, obligation sets, evidence statuses, leaves, and inference steps satisfy the profile.Each derivation leaf must correspond to a committed input, and required positive and negative conditions must be represented.
  • Decision Derivation Verification: VerifyDerivation is profile-relative rather than a universal proof system.
  • ERC Binding: ERC verification binds the release contract to the supplied derivation without requiring an independent evaluator to serialize an identical derivation.
  • Semantic Replay: Semantic replay requires matching decisions and reasons plus a derivation that verifies under the replayed bundle.Different valid derivation encodings may support the same replay result.

4.7 Invalidation, Grant State, and Atomic Redemption

EBL-Core prevents reuse of an outdated release decision and requires redemption, lifecycle transitions, and protected effects to share an authoritative linearization order.

  • Invalidation: An ERC becomes non-reusable when candidate identity, policy versions, evidence, required statuses, context, intent binding, validity, or derivation verification changes.Invalidation prevents reuse of the earlier result; a current decision requires new adjudication.
  • Grant State: All transitions from ISSUED share one authoritative linearization order, making overlapping revoke, expiry, and redemption requests deterministic.The first linearized transition determines whether redemption succeeds or the grant reaches a terminal denial state.
  • Atomic Redemption: Successful redemption requires validation, grant consumption, and the protected effect to share one logical linearization point.Atomic transactions, version-conditional commits, or equivalent mechanisms may realize this requirement.
  • Atomic Redemption: A validation step followed by an interleavable state change and later effect is not conforming R-Success.
  • Grant State: Redemption denies when validation fails, the grant is not ISSUED, or linearization cannot be established.

4.8 Conditional Security Propositions

The conditional propositions establish action binding, root-policy dominance, evidence-obligation safety, replay consistency, single-use consumption, and interface-local enforcement under explicit assumptions.

  • Exact Action Binding: A verified ERC cannot redeem a decision-relevantly different candidate under collision resistance and successful R-Success application.The candidate-identity equality in R-Success prevents substitutions such as changing the recipient.
  • Root-Policy Dominance: Operational Policy cannot weaken Root Policy when root permissions and obligations are immutable and policy predicates compose conjunctively.The result does not establish that the root policy itself is substantively correct.
  • Evidence-Obligation Safety: Every root and operational obligation must resolve to VALID for positive adjudication; UNKNOWN, MISSING, EXPIRED, and CONFLICT deny the positive rule.This concerns obligation resolution, not the external truth of evidence assertions.
  • Semantic Replay Consistency: Semantic replay produces the same decision and reason for closed, canonically equivalent bundles under deterministic evaluation assumptions.Hidden clocks or implementation-dependent iteration order would invalidate the conclusion.
  • Single-Use Grant Consumption: At most one concurrent Redemption of a grant can apply R-Success and produce the protected effect under one authoritative, linearizable grant-state object.If revocation or expiry linearizes first, no Redemption succeeds; a nonce alone is insufficient.
  • Conditional Interface Enforcement: Conditional interface enforcement depends on complete mediation, exact candidate application, verified ALLOW ERCs, linearized redemption, and declared trust assumptions.The proposition is interface-local and does not establish deployment-wide enforcement.

5 EBL-Core Conformance Profile and Integration Model

The EBL-Core profile separates adjudication, ERC verification, grant issuance, and redemption while requiring deterministic, closed inputs and explicit lifecycle controls for one canonical action.

  • Integration Model: The integration model separates deterministic adjudication, ERC generation and verification, grant issuance, and linearized redemption of the protected effect.The ERC binds release conditions but does not itself release execution authority.
  • Candidate and Inputs: A conforming candidate is one fully materialized, schema-valid, deterministically canonicalizable action containing every decision-relevant parameter.Candidate-profile completeness and Effector fidelity remain explicit assumptions.
  • Policy and Evidence: Operational Policy may add obligations but cannot remove, weaken, rename, or reinterpret Root Policy obligations.
  • Candidate and Inputs: Input closure requires adjudication to depend only on the committed bundle and referenced profile semantics, with external observations materialized in evidence or context.Undeclared resolver state, clocks, or mutable process values cannot affect the decision.
  • ERC and Redemption: ERC verification establishes consistency with the original adjudication but does not establish that current redemption conditions remain valid.Redemption separately checks current policy, evidence, context, intent binding, and lifecycle conditions.
  • ERC and Redemption: Successful redemption consumes the grant through a linearized transition, and revocation, expiry, and redemption share the same authoritative lifecycle state.The first transition from ISSUED determines the terminal state.
  • Scope: The baseline is single-candidate and single-use, and conformance claims remain scoped to the declared interface rather than all possible effect-producing paths.Level 2 is the minimum level for claiming EBL-Core execution-release conformance.

6 Evaluation and Validation Strategy

The evaluation separates semantic conformance, implementation behavior, and deployment assumptions, then tests EBL-Core through executable artifacts, mutation vectors, lifecycle checks, and bounded baseline mapping.

  • Evaluation scope: The evaluation distinguishes precise semantic definitions, correct implementation, and deployment satisfaction of execution-boundary assumptions.Conformance tests can validate the profile without establishing deployment security or implementation correctness.
  • Research questions: EBL-Core is evaluated through four questions covering obligation representation, cross-implementation decision equivalence, residual abstraction, and execution-boundary or grant-lifecycle failures.The questions require typed semantic inputs, equivalent decisions and reason codes, explicit integration categories, and lifecycle/concurrency tests.
  • Reference artifact: The reference artifact provides schemas, deterministic canonicalization, commitments, adjudication, ERC and grant operations, independent verification, Semantic Replay, and an in-memory grant store.The store uses its lock as the logical linearization point for the protected test effect.
  • Test design: The retained corpus tests positive, negative, boundary, ordering, and adversarial mutations across candidate, policy, evidence, context, derivation, ERC, and grant lifecycle states.Lifecycle checks include terminal states, duplicate Redemption, derivation and ERC mutation, and denial of Grant Issuance from DENY ERCs.
  • Baseline positioning: Table 1’s literature-based mapping finds the mandatory EBL-Core contract non-native as a whole to all six compared abstractions, without showing they cannot express its conditions.The paper identifies adapter-based comparison as the stronger future evaluation.

8. Grant Issuance

The validation strategy treats conformance as mutation rejection and lifecycle correctness, while limiting performance and security claims to the included artifact, profile, and deployment assumptions.

  • Conformance scenarios: Future scenarios must test permitted traces, obligation-state denials, policy restrictions, post-ERC mutations, and grant lifecycle and concurrency behavior.Unrepresentable ambiguities should be recorded as profile gaps or extension requirements rather than resolved by unstated evaluator behavior.
  • Validation boundaries: Scenario coverage across domains would test abstraction reuse but would not establish domain-complete safety properties or safe real-world outcomes.Deployment claims remain conditional on explicit authority, trust, Effector-fidelity, and mediation assumptions.
  • Mutation and lifecycle checks: Candidate, evidence, policy, context, derivation, ERC, and grant mutations must reject stale or inconsistent bindings and prevent terminal grants from returning to ISSUED.Concurrent Redemption must linearize validation, the protected effect, and the ISSUED-to-CONSUMED transition.
  • Performance scope: Performance evaluation should vary policy, obligation, evidence, candidate, context, and derivation sizes while measuring each semantic operation separately.The paper rejects universal latency thresholds and requires operational bounds to be reported separately from semantic conformance.
  • Validation boundaries: The included package is an executable specification and test oracle for one financial-transfer profile, not a production security component or complete deployment validation.Its broader limitations include a standard-library implementation, one profile, an in-memory store, and no adapter comparison.

7 Discussion

EBL-Core is presented as a semantic contract connecting adjudication to authority release and Redemption, while explicitly separating those semantics from authorization replacement and deployment security.

  • Profile scope: EBL-Core defines a conformance profile connecting adjudication with the release and Redemption of action-scoped execution authority.Its contribution is narrower than a complete authorization architecture or AI safety system.
  • Complementarity: EBL-Core complements rather than replaces authorization mechanisms by requiring preservation of specified bindings and lifecycle roles at the execution boundary.Existing policy substrates may supply evaluation while EBL-Core standardizes the joint release-and-redemption contract.
  • Semantic roles: The profile jointly binds a trusted intent, canonical candidate, versioned policies, obligations, evidence, context, time, decision, and derivation, then separates ERC Generation, Grant Issuance, and Redemption.An ERC records release conditions, a grant represents released authority, and Redemption governs its exercise.
  • Intent limitations: Intent binding constrains execution relative to a trusted representation but cannot establish that the representation captures a person’s actual intention.The profile can detect later recipient substitution but not an erroneous original recipient selection without additional information.
  • Evidence limitations: VALID evidence discharges declared obligations under profile semantics but does not establish provider honesty, sensor accuracy, informed approval, or complete observation.Decision-Derivation Verification likewise establishes derivation from committed inputs, not that those inputs describe the external world.
  • Deployment assumptions: A valid grant is a semantic requirement, whereas requiring every effect-producing path to use it is a deployment property involving mediation, authority topology, and bypass analysis.Effector fidelity, protected components, credentials, and alternative paths remain outside the core semantic guarantee.

8 Conclusion

The paper identifies a missing common contract at the transition from AI-generated candidates to execution authority and proposes EBL-Core to bind that transition explicitly.

  • Motivation: Existing authorization, policy, runtime, provenance, and guardrail mechanisms do not necessarily impose common semantic conditions on the final transition to execution authority.The gap concerns the interface among mechanisms rather than the absence of those mechanisms individually.
  • Contribution: EBL-Core binds intent, a canonical candidate, versioned policies, evidence obligations, typed evidence, context, time, and a verifiable derivation through an ERC.A verified ALLOW ERC may support Grant Issuance, while Redemption governs exercise of the resulting authority.
  • Scope: Its required properties include candidate binding, root-policy dominance, evidence handling, deterministic adjudication, derivation verification, and single-use linearized Redemption.The paper limits these properties to semantic conformance rather than human-intent correctness, evidence truth, universal mediation, or external outcomes.
  • Future work: Future validation should add independent implementations, interoperability experiments, broader conformance suites, integration adapters, and domain-specific profiles.These extensions are intended to evaluate execution-release semantics across heterogeneous AI-agent systems.
Loading 2609.11596v1…