Checking · Contacting the Aiyo Runtime Decision Point. · —
← All posts
Protocol Launch

Introducing AEAP — the Aiyo Execution Authorization Protocol

An open protocol for authorization at the composition boundary between autonomous intent and consequential execution. Pre-execution authorization. Portable cryptographic receipts. Independent verification. Verify First. Execute Second.

By the Aiyo Team · October 4, 2026

Today we are publishing the first public draft of AEAP — the Aiyo Execution Authorization Protocol — at github.com/aiyoplane/aeap, under Creative Commons Attribution 4.0 for the specification prose and Apache License 2.0 for the conformance test vectors.

AEAP defines a new class of authorization protocol: one designed specifically for the moment when an autonomous or semi-autonomous system has formed an Intent to perform a consequential action but has not yet executed it. The protocol specifies how a Runtime Decision Point evaluates that Intent against the Protected Party's Policy using Evidence Signals from the surrounding environment, produces a ternary Verdict (ALLOW, ESCALATE, or BLOCK), and emits a cryptographically-signed, portable Execution Receipt that any downstream system can verify offline — without ever talking to the system that made the decision.

This post explains what AEAP is, why we published it as an open protocol, and how it composes with the authorization ecosystem that already exists.

The problem AEAP solves

Autonomous systems — AI agents, workflow engines, machine-to-machine processes — are now routinely proposing to perform actions with real-world consequences. They move money. They deploy code. They write to systems of record. They dispatch purchase orders. They invoke tools whose effects persist after the tool call returns.

Every one of those consequential actions is an authorization problem. And the existing authorization stack was not designed for it.

Identity systems answer who is this acting principal. Authentication protocols answer can we prove the claimed identity. Delegation frameworks answer is this principal authorized to act on behalf of another. All of these are necessary. None of them answer the question that actually matters at the moment of execution:

Should this specific consequential action execute right now, under the Protected Party's current Policy, with the Evidence Signals available at this moment?

That is the runtime execution authorization question. It is distinct from identity. It is distinct from delegation. It is distinct from policy management. It is distinct from execution orchestration. It is the question that sits at the specific boundary between intent formation and execution.

AEAP defines a protocol — a vocabulary, an architectural primitive, a set of invariants, and a verification mechanism — specifically for that boundary.

The five-layer agentic authorization stack

Before we describe AEAP, it is worth placing it in the context of the authorization ecosystem that is converging around autonomous systems. Several related protocols address adjacent questions. AEAP composes with them; it does not replace them.

LayerQuestion answeredRepresentative protocols
Layer 1 — Identity / delegated accessWho is this agent acting for, and may it access this resource?Okta XAA, ID-JAG, OAuth 2.1, Microsoft Entra, Auth0
Layer 2 — Human mandate / delegated authorityDid a human authorize this bounded consequential act?Human Agency Protocol (HAP)
Layer 3 — Agent operation authorizationIs this agent operation authorized within the user's delegated authority?Alibaba / Cisco AOA, OpenA2A AAP
Layer 4 — Runtime execution authorizationShould this exact consequential action execute right now under the applicable policy, evidence, and runtime conditions?AEAP, ExecLayer, OxDeAI, Veto, CapFence
Layer 5 — Execution evidence / receiptsCan another system independently prove what was authorized, under what conditions, and whether the executed action matched the authorized act?SCITT Permit (IETF), DRP (IETF), EMILIA (IETF), AAARP, parts of AEAP

AEAP sits at Layer 4, with its Execution Receipt model spanning Layer 5. Our specification includes explicit Interop Profiles for consuming HAP mandate tickets, Okta ID-JAG grants, and Alibaba/Cisco AOA tokens as Evidence Signals — because AEAP is designed to compose with these systems, not to replace them.

An emerging category — and why a protocol matters

AEAP is not the only effort recognizing that runtime access decisions alone cannot govern consequential autonomous actions. The architectural gap between may this actor perform a class of action and should this specific consequential action execute right now, under the Protected Party's current Policy is becoming visible from several directions at once.

Capriola's "Runtime Authorization Is Not Execution Authorization" (September 2026) articulates the same distinction and proposes A2SPA (Agent-to-Secure Payload Authorization) as a mechanism for cryptographically binding authorization to the exact action payload at the execution boundary. The IETF Adaptive Authorization draft defines an Execution Handle and a Finality Sink that occupy architecturally adjacent territory. The IETF SCITT Pre-Execution Permit, DRP, and EMILIA drafts address overlapping concerns from the receipts-and-evidence direction.

Multiple independent architects converging on the same missing layer is not competition — it is category formation. AEAP's contribution is to publish the layer as an open protocol specification, with normative semantics, Interop Profiles for the identity-layer protocols above it, and a conformance test vector artifact that forces independent implementations to produce interoperable outputs. A mechanism like A2SPA could be an implementation detail inside an AEAP-conformant RDP; an AEAP Execution Receipt can be consumed as evidence by an A2SPA-shaped system. The two operate at different levels of abstraction, and the semantics that make them interoperable are what AEAP is for.

This is why we published AEAP as a specification first and a product second. The authority of a protocol is established by adoption and demonstrated interoperability, not by the identity of its author. The emerging category needs a layer where independent implementations agree on what an authorization decision looks like, how it is attested, and how it is verified without coordination with the issuer. That is the layer AEAP defines.

The architectural insight: Runtime Decision Point and Composition Boundary

The core architectural primitive AEAP specifies is the Runtime Decision Point — abbreviated RDP throughout the specification. An RDP is the component that:

  1. Receives an Intent — a structured representation of exactly one proposed consequential action
  2. Resolves the Protected Party's Policy — declarative rules authored by the party being protected
  3. Collects the required Evidence Signals — information the Policy references for its evaluation
  4. Produces a Verdict — ALLOW, ESCALATE, or BLOCK
  5. On ALLOW or ESCALATE, emits an Execution Receipt — a cryptographically-signed, portable attestation of the decision

The RDP is invoked at a Composition Boundary — the specific location in a system where the authorization decision happens. For an AI agent framework, the Composition Boundary might be the moment the framework is about to dispatch a tool call. For a payment pipeline, it might be the moment a transfer is about to be committed to a rail. For a CI/CD system, it might be the moment a deploy is about to be released to production. AEAP is substrate-neutral: the same architectural primitive sits before any class of consequential action.

Five invariants

Every AEAP-conformant RDP satisfies five invariants. These are the invariants that define what it means to be an RDP under this specification:

  1. One decision per Consequential Action. The RDP evaluates one Intent and produces one Verdict for one action. No batching. No session-level authorizations. No "permit me to spend $10,000 over the next hour."
  2. The decision occurs strictly between Intent and Execution. After the Intent is fully formed. Before the action takes effect. Not at session start. Not post-hoc. The authorization decision inhabits a specific temporal window.
  3. Policy is authored by the Protected Party. The RDP does not inject its own rules. The party exposed to the consequences of the action authors the Policy that governs it.
  4. Authorization decisions MUST be independently verifiable. Receipts are cryptographically signed and verifiable offline against a published JWKS — without any live callback to the issuing RDP. This is what makes AEAP a protocol rather than an API.
  5. Fail closed by default. In any ambiguous, erroneous, or indeterminate condition, the RDP produces BLOCK. Fail-open is not permitted at the RDP level.

These invariants propagate through every section of the specification. They are the reason AEAP's architecture is coherent across Intent, Policy, Evidence, Verdict, Receipt, Composition Boundary, and conformance.

The DMARC precedent

AEAP's architectural pattern has a direct precedent — one that has been operating at internet scale for more than a decade: DMARC (Domain-based Message Authentication, Reporting, and Conformance; RFC 7489, published 2012).

Structurally, DMARC is a policy gate at the email execution boundary. The sender authors a policy published at a canonical DNS record. The receiver cryptographically authenticates the incoming message via DKIM. The policy produces a requested disposition — none, quarantine, or reject — applied receiver-side immediately before delivery. Feedback flows back to the policy author. Progressive rollout is supported through the pct mechanism.

DMARC gave the email ecosystem something it previously lacked: a protocol by which a sender's authorization policy for its own messages could be expressed, independently verified by any receiver, and enforced at the execution boundary. Major mailbox providers — Google, Microsoft, Yahoo, Fastmail, Proton — all honor it. More than a decade of production evidence at internet scale.

AEAP generalizes the pattern. The authored party changes from domain owner to Protected Party. The signed artifact changes from DKIM signature to Execution Receipt. The disposition changes from mail-delivery outcome to execution-authorization Verdict. The ternary verdict expands from none/quarantine/reject to ALLOW/ESCALATE/BLOCK. The staged rollout vocabulary matches: DMARC's p=none/p=quarantine/p=reject maps to AEAP's Shadow Mode and Enforce Mode discipline. The composition point is explicit in both.

DMARC does not prove AEAP will succeed. It does prove that this class of boundary-authorization architecture — policy authored by the protected party, evidence evaluated at the point of execution, a requested disposition at a well-defined composition boundary, feedback to the policy author, and a mechanism for staged rollout — can operate at internet scale. AEAP applies the same architectural discipline to a new substrate: autonomous consequential actions.

AEAP also materially extends the pattern in one direction that matters: a portable cryptographic authorization receipt. DMARC produces a receiver-side disposition; the disposition itself does not travel beyond the receiver. AEAP's Execution Receipt is Ed25519-signed, verifiable offline against a published JWKS, and carries the full runtime decision as a portable artifact any downstream system can verify without coordination with the issuing RDP. That is what makes the authorization decision cross trust boundaries.

The portable receipt — and why it matters

The most unusual commercial property of AEAP is that you don't have to believe the issuer to use its receipts.

A downstream verifier receives an Execution Receipt. The verifier confirms:

  1. The receipt's cryptographic signature validates against the issuer's published JWKS.
  2. The receipt's intent_digest matches the SHA-256 digest of the canonical Intent the verifier is presented with.
  3. The receipt's exp has not elapsed (for reliance on new execution) or that the receipt was issued before any claimed key compromise (for historical audit).
  4. The receipt's verdict is ALLOW.

All four checks are strictly offline. No live callback to the issuing RDP. No "ask Aiyoplane whether this is still good." The receipt carries the authorization decision as a self-contained, independently-verifiable artifact.

This matters for two reasons.

First, it dissolves vendor lock-in at the trust layer. An enterprise that deploys an AEAP implementation does not become dependent on the issuer's continued operation for its historical authorization records to remain verifiable. A receipt issued today will verify in ten years against the (archived) public key material even if the issuer no longer exists.

Second, it makes authorization composable across systems that do not trust each other. A GitHub Actions workflow can verify a receipt issued by an enterprise's internal RDP. A Shopify order fulfillment system can verify a receipt issued by a payment-rail authorization pipeline. A Kubernetes admission controller can verify a receipt issued by a CI/CD governance surface. The authorization decision travels; the issuing system does not need to be present.

This is the DMARC property, upgraded. DMARC's authorization decision stayed receiver-side. AEAP's authorization decision travels.

Evidence Signals — value, provenance, attestation

One of the architectural refinements AEAP introduces is a formal three-component decomposition of what counts as evidence. Every Evidence Signal the RDP evaluates has:

These are three different trust properties. An Evidence Signal with a value and a self-asserted provenance but no attestation is weaker than one with the same value and provenance plus a cryptographic signature from a trusted issuer. AEAP requires implementations to distinguish these three components rather than collapsing them into a single notion of "the Policy received evidence."

This matters because it closes a specific class of trust confusion. If an Intent arrives containing {"actor_id": "anthropic_agent_123", "source": "Anthropic"}, that payload has a value and a provenance claim. It does not have attestation that Anthropic in fact issued the identity. Treating the source label as evidence of origin is incorrect — but it is exactly the mistake implementations make if the specification does not force the three-component distinction.

The specification identifies five Evidence Signal categories (Identity, Authority, State, Settlement, External), permits implementations to specialize in whichever categories matter most for their domain, and leaves the specific attestation mechanism to the Policy's own trust declarations.

The verdict is ternary, not binary

AEAP's Verdict is one of three values: ALLOW, ESCALATE, or BLOCK. No other values are permitted. No probabilistic verdicts. No conditional verdicts. No composite verdicts.

ESCALATE is a first-class Verdict, not a "soft ALLOW" or a "soft BLOCK." It is the Policy explicitly routing a Consequential Action to a human-in-the-loop (or other out-of-band) decision process. Every ESCALATE Verdict carries a stable escalation_id that correlates the pending escalation across the resolution workflow and into any receipt lineage that follows.

The Composition Boundary enforcement rules are correspondingly strict. On BLOCK, the Composition Boundary MUST NOT execute. On unresolved ESCALATE, the Composition Boundary MUST hold the action pending resolution. On ALLOW, the Composition Boundary MAY permit execution — but is not required to execute. AEAP prohibits unauthorized execution; AEAP does not require authorized execution. That distinction is normative and preserved consistently across the specification.

Why we published it as an open protocol

Several reasons.

First, the architectural pattern is only valuable if it is interoperable. A single-vendor "authorization API" that happens to produce signed receipts is a product. A specification that any party can implement, with conformance test vectors proving that implementations produce identical bytes on identical inputs, is a protocol. We want AEAP to be a protocol. The spec is CC BY 4.0; the test vectors are Apache 2.0; the reference implementations are Apache 2.0. There is no vendor-controlled gate.

Second, Aiyoplane, Inc. authored AEAP; Aiyoplane does not own AEAP's authority. Authorship is distinct from authority. The specification contains this normative statement at §1.1. The authority of AEAP as a protocol is established by adoption, interoperability demonstrated by Appendix A conformance, and the collective practice of the implementing ecosystem — not by the identity of its author. The protocol's technical integrity does not depend on any specific organization — including Aiyoplane, Inc. — continuing to operate a commercial RDP.

Third, the deployment model agnosticism is architecturally load-bearing. AEAP's Composition Boundary is deployment-model-neutral: an RDP may be operated in-process by the Protected Party (self-hosted), as a managed service by a commercial provider (hosted), or in a hybrid configuration where some Composition Boundaries invoke a local RDP and others invoke a remote one. The conformance requirements apply identically across deployment models. Enterprises choose the deployment that fits their constraints.

Fourth, portability requires openness. The portable-receipt property only produces real commercial value if the receipts are produced by independently-maintained implementations that are known to produce interoperable outputs. The second-implementation requirement forces this: we built both a Node implementation (@aiyoplane/mcp-authz, @aiyoplane/verify) and a Python implementation (aiyoplane-mcp-authz, aiyoplane-verify), maintained as separate codebases with no vendored code sharing between them. Receipts produced by one implementation can be verified by the other. That mutual independence is the proof that AEAP is a specification rather than a reference-library-with-wrappers.

Reference implementations and the ecosystem shipped

Alongside the specification, we have shipped the first generation of reference implementations and ecosystem adapters. All under Apache 2.0:

A companion blog post goes into more detail on the ecosystem: The AEAP Ecosystem — October 2026.

Aiyoplane's specialization within AEAP

AEAP is general-purpose. The specification is substrate-neutral; it treats payment, deployment, procurement, data write, agent delegation, and any other class of consequential action as first-class.

Aiyoplane, Inc. — the company that authored AEAP — has a specific commercial focus within that general space: settlement-verified execution authorization. Aiyo's own implementation of AEAP specializes in making verified on-rail economic settlement a first-class Evidence Signal. A verified payment can itself be the authorization-unlocking evidence for a subsequent consequential action under the Protected Party's Policy.

This is the primitive we have been calling "where payment acquires execution meaning." Aiyo exists specifically for machine commerce — autonomous AI agents transacting on behalf of their principals, machine-to-machine payment flows, settlement-gated fulfillment pipelines. The settlement-verified specialization sits inside AEAP's open Evidence Signal model; other AEAP implementations may specialize differently.

This distinction matters: AEAP is the open protocol; Aiyo is the ecosystem and the commercial implementation specialized for a specific substrate. Both are real; they are different artifacts.

The road to v1.0

Today's release is AEAP v0.9.1-DRAFT. The specification is complete through §14 and Appendices A-D. The architecture has been through two external review cycles with substantive revision at each pass.

The gating artifact for AEAP v1.0.0 is the Appendix A conformance test vector suite. Per §A.3, the vectors will prove that two independent implementations evaluating the same canonical Intent against a Policy identified by the same Policy digest, with the same canonical set of Evidence Signal values, produce the same Verdict, the same reason code, and the same canonicalized signing input bytes. When both the Node and Python reference implementations pass all vectors identically, we promote to v1.0.0.

Independent implementations by third parties are welcomed under the same conformance criteria. Implementers do not need to coordinate with Aiyoplane except insofar as the test vectors evolve across specification versions.

How to engage

What AEAP is not

By way of closing precision: AEAP is not an identity protocol. It is not a payment protocol. It is not an execution orchestration protocol. It is not a policy expression language. It is not an AI safety framework. It is not an agent operation system.

AEAP is the authorization decision layer at the specific moment between intent and execution. The surrounding layers — identity, delegation, agent operation, payment, orchestration, execution evidence — are themselves well-defined protocols or product categories. AEAP composes with all of them. It replaces none of them.

That architectural restraint is deliberate. A protocol that tries to subsume adjacent layers tends to collapse under its own scope. AEAP is deliberately narrow at the base and extensible at the Profile layer. Future AEAP Profiles will formalize additional composition surfaces (we have already specified HAP, Okta XAA/ID-JAG, and Alibaba/Cisco AOA Profiles in §11-§13); the base protocol remains focused.

Why now

The agent economy is reaching a scale where ad-hoc authorization is no longer a safe default. Autonomous systems are moving money. They are deploying infrastructure. They are managing records of consequence. The question of what counts as a valid authorization for an autonomous action is becoming load-bearing — not because anyone has solved it badly, but because the frequency and consequence of autonomous actions are growing faster than the mechanisms for governing them.

We think the right response is an open, interoperable, independently-verifiable protocol — one that enterprises can run themselves, that third parties can implement, that composes with the identity and delegation protocols already in production, and that produces a portable artifact any downstream system can verify without trusting the issuer.

AEAP is our attempt at that protocol. It is public today. It is open to review, independent implementation, and composition. The authority of AEAP will be established by adoption, not by our continuing to operate it.

Verify First. Execute Second.