AEAP — the Aiyo Execution Authorization Protocol
v0.9.1-DRAFT shippedThe open protocol specification Aiyoplane, Inc. authors and maintains. Published October 4, 2026 for review and comment ahead of v1.0. CC BY 4.0 for the specification prose; Apache 2.0 for the conformance test vectors. Independent third-party implementations welcomed under the same conformance criteria.
Live · GitHub
The AEAP specification. Intent → Policy → Evidence → Verdict → Receipt → Composition Boundary → Rollout → Interop Profiles → Conformance. Five invariants that define a Runtime Decision Point. Portable cryptographic Execution Receipts verifiable offline. Deployment-model-agnostic: self-hosted, Aiyo-hosted, or hybrid implementations are all equally conformant.
git clone https://github.com/aiyoplane/aeap
Security model & responsibility boundaries
Four questionsAny security claim about an authorization system decomposes into four distinct questions. AEAP addresses some of them directly as protocol guarantees, informs others, and explicitly names which are implementation, executor, or Protected Party responsibilities. The honest answer per question — including what we do and do not guarantee — is below. The full maturity state across every control is captured internally; investor and enterprise security reviews are welcomed to request it under NDA.
1 · Receipt authenticity
AEAP guarantees
Did a legitimate Runtime Decision Point issue this receipt? AEAP guarantees receipt authenticity via Ed25519 signatures over RFC 8785 JCS-canonicalized bytes, verifiable offline against the Issuer's published JWKS. Six distinct verifier result codes separate "signature mathematically verifies" from "the signing key is still trustworthy for reliance" — including a specific
COMPROMISED_KEY code distinct from VERIFIED and INVALID.npx @aiyoplane/verify path/to/receipt.txt
2 · Decision integrity
AEAP addresses
Was the authorization decision sound given the policy and evidence? AEAP guarantees deterministic Policy evaluation (§4), fail-closed defaults (§2.2 invariant 5), and a three-component Evidence envelope (Value / Provenance / Attestation). Policy correctness itself — did the policy author express the intended rules? — is a Protected Party responsibility that AEAP does not try to solve. Policy linting, versioning, simulation, and review tooling are on the roadmap as operational infrastructure around the protocol.
3 · Enforcement integrity
Composition Boundary primitive
Did the Composition Boundary actually enforce the Verdict? AEAP defines the Composition Boundary primitive (§9) and specifies ternary verdict semantics: BLOCK must not execute, unresolved ESCALATE must hold, ALLOW may permit. Reference adapters for MCP, LangChain, LangGraph, OpenAI Agents SDK, CrewAI, Microsoft Agent Framework, Google ADK, Claude Agent SDK, and Spring AI implement the pattern. Enforcement in a given deployment — ensuring the gated action is reachable only through the boundary and not via an admin path, sibling API, or direct database write — is the Executor's responsibility.
4 · Operational accountability
Partial · lineage closure optional
Can an operator reconstruct what was authorized, by whom, under what policy, with what evidence, and whether the action was executed? AEAP defines the Receipt (§7) and optional lineage-closure callbacks (§7.5). The intent → receipt portion is shipped. Complete end-to-end execution lineage, including observed outcomes, requires cooperative Executor participation.
Explicitly named non-guarantees
The honest statements of what AEAP does NOT guarantee. Naming the responsibility boundary so Protected Parties and Executors know what they own.
Exactly-once execution
Executor responsibility
AEAP prevents the same authorization decision from being re-evaluated within a replay window (§3.4). It does NOT prevent the authorized action from being executed more than once. If an executor successfully performs an action, crashes before recording completion, and retries, the receipt still verifies and the action can duplicate. Downstream idempotency is the Executor's responsibility — typically via idempotency keys tied to
intent_id, atomic state transitions, or payment-rail / database-level deduplication.Pre-expiration receipt revocation
Implementation-specific
AEAP Core does not provide a mechanism for revoking an individual receipt before its
exp. Portable offline verification is a deliberate design choice — Executors do not need to reach the Issuer at verification time. Protected Parties requiring earlier withdrawal use one of two patterns: (a) short-lived receipts with re-evaluation — issue short exp and require the Executor to re-submit the Intent per sensitive action; (b) an online status mechanism as an implementation-specific control. A future AEAP profile may standardize the latter.Policy correctness
Protected Party responsibility
AEAP evaluates whatever Policy is authored. A Policy with a misconfigured threshold (e.g., a decimal placement error allowing a payment two orders of magnitude larger than intended) will produce a deterministic ALLOW. The receipt faithfully attests to the evaluation. The authorship of a correct Policy is operational and belongs to the Protected Party. Operational tooling for policy authoring, review, simulation, and rollback is roadmapped as infrastructure around the protocol, not a protocol guarantee.
Evidence source truthfulness
Attestation issuer responsibility
AEAP's Evidence envelope (§5) requires Value / Provenance / Attestation on every signal the Policy evaluates. AEAP conformant implementations evaluate the Attestations the Policy declares. AEAP does not guarantee that the Attestation issuer is honest, that the Attestation reflects the current real-world state of the external system, or that the Attestation issuer's own key infrastructure is sound. Selecting trusted Evidence sources is a Protected Party design decision.
AEAP reference implementations
17 shippedInstallable implementations any developer, auditor, or downstream system can use today. Two independent language implementations (Node + Python) demonstrate AEAP's interoperable implementability — they share no vendored code and derive their behavior independently from the specification. Every package is Apache 2.0 licensed with a published README, versioned releases, and a public issue tracker.
Receipt verifiers
Surfaces that read an AEAP execution receipt and report whether it is cryptographically authentic and what verdict it carries. Node + Python verifiers, the GitHub Marketplace Action, and the Homebrew CLI distribution. All of them consume receipts; none of them produce new authorization decisions.
Live · npm
Offline Ed25519 verifier for Aiyo execution receipts. Any receipt Aiyo issues, verifiable against Aiyo's published JWKS in one command — no Aiyo-side infrastructure required at verification time.
npx @aiyoplane/verify path/to/receipt.txt
Live · PyPI
Python port of the AEAP receipt verifier. Same receipt format, same JWKS, same Ed25519 verification — maintained as an independent codebase. The second-implementation proof that AEAP is a protocol, not a Node-ecosystem artifact.
pip install aiyoplane-verify
Live · GitHub Marketplace
GitHub Marketplace Action — verify an AEAP execution receipt inside any GitHub Actions workflow. Fail-closed default. Separate
verified and verdict outputs (cryptographic authenticity vs. authorization decision). Pinned verifier version by default.uses: aiyoplane/verify-receipt-action@v1
Live · Homebrew
Homebrew tap for the Aiyo CLI verifier. Wraps
@aiyoplane/verify as a native macOS command so engineers can verify a receipt from the terminal without a Node runtime installed.brew install aiyoplane/tap/aiyo
AEAP Composition Boundary Adapters
Surfaces that attach the AEAP Runtime Decision Point to a specific framework's execution boundary. Each adapter is NOT adding Aiyo features to someone else's framework — it is the specific way AEAP's Composition Boundary primitive attaches to that framework's native tool, node, or middleware abstraction. The mcp-authz packages are the foundational adapters (attaching to the MCP tool-invocation boundary) and provide the reusable primitives — AiyoAuthz middleware, LocalRdp / HostedRdp providers — that every subsequent framework adapter composes above. Shipped adapters cover MCP, LangChain, LangGraph, OpenAI Agents SDK, CrewAI, Microsoft Agent Framework, Google ADK, Claude Agent SDK, and Spring AI across Node, Python, and JVM ecosystems.
Live · npm + GitHub
Node Composition Boundary Adapter for the MCP tool-invocation boundary — and the foundational AEAP primitive package. Carries the AiyoAuthz middleware, LocalRdp + HostedRdp providers, Intent / Policy / Verdict evaluation, and receipt signing. Every subsequent AEAP Composition Boundary Adapter in the Node ecosystem composes above this package.
npm install @aiyoplane/mcp-authz
Live · PyPI
Python Composition Boundary Adapter for the MCP tool-invocation boundary — and the foundational AEAP primitive package for the Python ecosystem. Independent codebase from the Node sibling, same composition semantics, idiomatic Python decorator surface. Every subsequent Python AEAP Composition Boundary Adapter composes above this package.
pip install aiyoplane-mcp-authz
Live · npm
AEAP Composition Boundary Adapter for LangChain (Node). Wraps
@langchain/core/tools Tool / DynamicTool with the AEAP RDP via @aiyoplane/mcp-authz. Fail-closed defaults. Ternary verdict composition into LangChain's native invocation flow.npm install @aiyoplane/langchain
Live · PyPI
AEAP Composition Boundary Adapter for LangChain (Python). Wraps
langchain_core.tools.BaseTool with the AEAP RDP via aiyoplane-mcp-authz. Independent Python implementation; same ternary verdict shape as the Node sibling.pip install aiyoplane-langchain
Live · npm
AEAP Composition Boundary Adapter for LangGraph (Node). Wraps LangGraph.js node functions so every graph transition into a consequential action produces an independently verifiable Execution Receipt. The Composition Boundary sits at the graph node — architecturally the strongest fit for AEAP.
npm install @aiyoplane/langgraph
Live · PyPI
AEAP Composition Boundary Adapter for LangGraph (Python). Wraps LangGraph node functions via
aiyo_gate decorator or wrap_node function form. Receipt attached to graph state on ALLOW. Independent Python implementation of the same adapter contract as the Node sibling.pip install aiyoplane-langgraph
Live · npm
AEAP Composition Boundary Adapter for the OpenAI Agents SDK (Node). Wraps
tool.execute with the AEAP RDP via @aiyoplane/mcp-authz. Composes with the SDK's own guardrails, handoffs, and session machinery — does not replace them.npm install @aiyoplane/openai-agents
Live · PyPI
AEAP Composition Boundary Adapter for the OpenAI Agents SDK (Python). Wraps Python callables before
agents.function_tool registration. Decorator order: @function_tool outer, @aiyo_tool inner.pip install aiyoplane-openai-agents
Live · PyPI
AEAP Composition Boundary Adapter for CrewAI (Python-native framework). Wraps
crewai.tools.BaseTool subclass instances. Multi-agent crew composition is a textbook case where "may this crew member perform?" ≠ "should this specific action execute?" — the two layers compose.pip install aiyoplane-crewai
Live · npm
AEAP Composition Boundary Adapter for the Microsoft Agent Framework (Node — successor to AutoGen + Semantic Kernel). Two integration surfaces:
AiyoAgentMiddleware for the middleware chain and wrapAction for workflow nodes.npm install @aiyoplane/microsoft-agent-framework
Live · PyPI
AEAP Composition Boundary Adapter for the Microsoft Agent Framework (Python). Middleware class + wrap_action function form. Explicit "middleware for intercepting agent actions" in Microsoft's own docs is architecturally adjacent to the Composition Boundary.
pip install aiyoplane-microsoft-agent-framework
Live · PyPI
AEAP Composition Boundary Adapter for Google ADK (Python-first SDK). Wraps a Python callable before Google ADK tool registration. Especially relevant for Google ADK's code-execution and sandboxed-environment surfaces — prime AEAP territory.
pip install aiyoplane-google-adk
Live · npm
AEAP Composition Boundary Adapter for the Claude Agent SDK (Node). Wraps tool handlers with the AEAP RDP. Coding-agent surfaces (file write, command execution, dependency install, git push, deploy) are AEAP-shaped problems par excellence.
npm install @aiyoplane/claude-agent-sdk
Live · PyPI
AEAP Composition Boundary Adapter for the Claude Agent SDK (Python).
@aiyo_tool decorator form + wrap_tool_handler function form. Positioning: Claude decides what it wants to do; AEAP provides the independently verifiable authorization decision at the point of consequential execution.pip install aiyoplane-claude-agent-sdk
Live · GitHub
AEAP Composition Boundary Adapter for Spring AI (Java). First JVM adapter. Attaches the AEAP Runtime Decision Point to Spring AI's tool-calling surface via the
@AiyoGated annotation on existing @Tool methods, Spring Boot 3 auto-configuration, and policy YAML with the action_type / effect / amount_max schema shared with every other AEAP adapter. Issues Ed25519-signed Execution Receipts over RFC 8785 JCS canonical intent. Spring AI merged native tool-call confirmation on 2026-10-15 (PR #7157, milestone 2.1.0-RC1); this adapter is positioned to compose above that native mechanism — Spring AI handles the pause/resume, AEAP adds policy-driven ALLOW/ESCALATE/BLOCK semantics and portable receipts that travel across the other eight shipped adapters. The specific integration surface with native @Tool(requiresConfirmation = true) is in design-spike review; the shipped 1.0.0 works independently today and a follow-on release will add explicit native-confirmation composition once the integration is tested across approve, deny, altered-argument, expiration, and retry conditions.com.aiyoplane:aiyoplane-spring-ai:1.0.0
Rail adapters
4 live · 1 testnetPayment rails Aiyo's Runtime Decision Point observes for settlement evidence. Every rail collapses to the same evaluation shape: this specific payment resource, on this specific rail, actually received this specific amount, at this specific timestamp. Rail-agnostic by architectural design.
Open Payments
Live · Production
Open Payments incoming-payment resource observation, wallet-agnostic across any OP-native provider. Native Aiyo integration since Grant for the Web ecosystem work.
x402 (USDC on Base)
Live · Base Sepolia
Verification of the
X-PAYMENT response header and on-chain USDC settlement against the expected receiver and amount. Live on Base Sepolia, architecturally validated for Base mainnet.Tempo — Machine Payments Protocol (MPP)
Testnet · Mainnet in progress
MPP adapter shipped September 1, 2026, manually verified end-to-end against Tempo testnet with real on-chain pathUSD settlement. Ships with the mppx issue #395 mitigation baked in at the adapter boundary. Mainnet hardening targets completion within one week of this page's publication.
Coinbase via x402
Live · Production
Coinbase adapter integrating x402 with USDC settlement observation on Base. Composes with Aiyo's rail-agnostic authorization contract.
Crossmint via x402
Architecturally validated
Crossmint integration through the x402 adapter shape. Architectural validation complete; production hardening on the roadmap.
Wallet, signing, and identity integrations
3 liveNon-custodial by architectural doctrine. Aiyo never holds, accepts, or transmits funds; these integrations compose with the wallets, signers, and identity providers the merchant already runs.
GateHub
Live · Production
Open Payments-native wallet integration. Public-read wallet verification, GateHub-hosted receiving-wallet flow for Aiyo merchants who accept OP grants.
Turnkey
Live · Production
Signing infrastructure for merchants running Aiyo with programmatic wallet control. Aiyo composes above Turnkey rather than replacing it — Turnkey remains the signer of record.
Privy
Live · Production
Identity attestation adapter. Privy remains the identity provider; Aiyo consumes attestations as an evidence signal to the Runtime Decision Point.
Public demos
3 liveLive, hosted demonstrations of Aiyo's primitive in three different modes. Every demo is publicly accessible; no signup required to inspect.
Live · Hosted
A payment stream running against Aiyo in real time. Trigger a policy denial and watch settlement halt in-flight — no retry, no rollback, no silent failure. Proves: the RDP enforces continuously, not just at authorization.
Live · Hosted
Paste any EVM transaction hash, watch Aiyo's verifier run against the chain in real time. Proves: the API contract is real, versioned, and inspectable end-to-end.
Live · Hosted
The Runtime Decision Point composed above an MCP server, running in your browser. Five scenarios covering payment and non-payment consequential actions through the same primitive. Proves: action-agnostic.
Public engineering research
Published + on requestAiyo's architectural surface published in writing. Blog posts are public; the deeper reference artifacts (Reference Architecture, Governance Pattern Library, Design Partner Governance Workbook, and the 28,000-word Competitive Dossier) are available to design partners and to investors under NDA.
Aiyo Blog
Live · Public
Engineering-investigation writing from the Aiyo team plus the founder's voice. Every ship gets a post; every post carries a date and inspectable evidence.
Reference Architecture v1.8
On request
The full architectural specification: Runtime Decision Point, execution receipts, evidence signals, composition boundaries, invariants. Available to design partners and investors on request.
Governance Pattern Library v1.6
On request
36 catalogued authorization-gate patterns with versioned promotion conventions. The patterns that show up across boundaries where autonomous consequential actions execute.
Design Partner Governance Workbook v1.6
On request
13 open design questions Aiyo works through with design partners during onboarding. The specific conversations that need to happen before a merchant enables enforcement.
Competitive Dossier — 2026-09-04
Under NDA
28,000-word primary-source analysis of 31 companies across four rings of the agent-authorization market, plus capability matrix and strategic recommendations. Available to investors under NDA.
Corporate
Legal identity, trademark, and the addresses of record for correspondence, service of process, and business operations.
- Legal name
- Aiyoplane, Inc.
- Entity type
- Delaware C-Corporation (stock)
- Incorporated
- October 2026
- Registered agent
- Harvard Business Services, Inc. · 16192 Coastal Highway, Lewes, DE 19958 · Sussex County
- Principal address
- 15900 W 10 Mile Rd, Ste 211 #328, Southfield, MI 48075
- Contact
- info@aiyoplane.com · +1 (877) 879-0434
- Authorized capital
- 10,000,000 shares Common Stock, $0.00001 par value (single class at inception)
How we hold this page honest
These are the rules the Trust surface is written under. Adopted deliberately; enforced everywhere.
- Every entry carries a status label and a date. Categories: Live · Production, Live · Testnet, Architecturally validated, On request, Under NDA. If we can't tell you which one applies, the entry doesn't appear.
- We publish what we've shipped, not what we're planning. Applications in flight, ecosystem partnerships under discussion, and roadmap items don't appear on this page until they're live or publicly discoverable.
- We don't publish revenue, paying-customer counts, or specific merchant names until case studies are opt-in and named by the merchant themselves.
- Testnet is testnet. If a rail adapter is verified against testnet but not mainnet, it's labeled that way explicitly. No inference of mainnet-readiness from testnet-hardening.
- Verification dates are the date we last confirmed the entry to be current — not the date it originally shipped, unless the two are the same.
- When we can't back a claim with a public link, we don't make it on this page. Every row above has a live URL, a published spec, or is explicitly marked "on request" or "under NDA."
Last updated: 2026-10-18 · Changelog tracks every substantive edit to this page.