AI-agent security often treats an authorization decision as the end of the control problem: a policy engine evaluates a proposed action, returns ALLOW, and the system proceeds. A new preprint from researchers at Chengdu Havenlon Security Technology argues that this collapses several different questions into one. Their EBL-Core proposal separates the decision that an action satisfies policy from the later release and use of authority to execute that exact action.

The distinction matters for agents that can move money, change infrastructure, deploy software, disclose protected information or trigger physical effects. In those settings, an action can be valid when it is reviewed and unsafe by the time it is executed because the policy version, evidence, context, payload or authorization state has changed. EBL-Core is an attempt to make those dependencies explicit and testable.

The paper inserts a boundary between ALLOW and execution

EBL-Core starts after a trusted component has converted a request into structured intent. It then binds that intent to one fully materialized candidate action, the applicable root and operational policies, evidence obligations, typed evidence, context and time.

The system produces what the authors call an Execution Release Contract, or ERC. The ERC records the decision and the conditions under which authority may later be released, but it is deliberately not the authority itself. A verified ALLOW ERC can support creation of a separate, action-scoped Execution Grant. When that grant is actually used, a Redemption step checks whether the relevant conditions still hold.

That separation is the central contribution. It prevents a successful decision from being treated as a reusable permission detached from the exact action and state that justified it.

Revalidation is designed to catch state drift

At Redemption time, the reference profile checks that the grant is still issued and bound to the same candidate, that the requested authority is within scope, and that the validity interval has not expired. It also rechecks decision-relevant state. Root and operational policy versions must match the committed versions, evidence and context identities must still match, the action must remain bound to the trusted intent, and every required evidence obligation must remain valid.

This is stricter than simply verifying a signed approval token. A cryptographically valid token can still describe an authorization that has become stale. EBL-Core makes freshness and state continuity part of the execution boundary.

The paper also requires operational policy to be non-weakening relative to root policy. A lower-level workflow may add restrictions, but it cannot silently delete or reinterpret requirements imposed by the root policy.

The artifact tests the contract, not production security

The authors include an executable reference artifact for one financial-transfer profile. Its retained validation summary reports 34 of 34 static vectors passing and 15 of 15 lifecycle checks passing. In 100 concurrency trials with 32 simultaneous Redemption attempts, exactly one Redemption and one protected test effect succeeded in each trial. One hundred revoke-versus-redeem race tests also ended in valid terminal states.

Those results are useful because they show that the proposed semantics can be implemented and tested. They are not evidence that EBL-Core is ready to secure a production bank, deployment platform or physical control system. The authors explicitly limit the claim: the artifact does not establish that human intent was interpreted correctly, that evidence is true, that every execution path is mediated, or that external effects faithfully match the approved action.

The current executable profile is also narrow. It covers a financial-transfer example. Infrastructure changes, software deployments, disclosures and physical actuation are described as future scenarios for a broader conformance corpus.

The practical lesson is to separate approval from capability

Aipolix’s analysis is that this paper exposes a recurring design mistake in agent governance: systems often record why an action was approved, but do not bind that approval strongly enough to the exact capability later exercised.

For a production agent, an approval event should not mean “this agent may now do something similar.” It should mean that a specific materialized action, under a specific policy and evidence state, may receive narrowly scoped authority for a bounded period. If the action, evidence, policy or context changes, the earlier approval should become unusable rather than being interpreted as a durable entitlement.

This design also reduces the value of prompt-level governance as the final control. Prompts can describe policy, and policy engines can decide whether conditions are met, but neither guarantees that the eventual side effect is the same action that was evaluated. The last control point must sit close to the system that can actually cause the external effect.

EBL-Core is a profile, not a new universal authorization system

The paper does not replace policy engines such as Cedar, Rego or XACML, capability systems, proof systems or runtime monitors. Its proposal is a common conformance contract for composing those mechanisms around one execution boundary.

That is an important limitation and also a strength. The authors are not claiming that one new token format solves agent security. They are defining observable conditions that different implementations can test: whether intent, candidate action, policies, evidence and context are bound together; whether the derivation can be verified; whether lower-level policy cannot weaken higher-level policy; and whether a grant can be redeemed only once under current conditions.

The next evidence needed is therefore not another conceptual diagram. It is interoperability and deployment testing across independently built implementations and across actions beyond the financial-transfer example. Until then, EBL-Core is best read as a concrete engineering proposal for where high-risk agent authorization should end and execution authority should begin.

Sources
- https://arxiv.org/abs/2609.11596
- https://arxiv.org/src/2609.11596v1/anc/results/validation-summary.json