The AEAP Ecosystem — October 2026

This is a companion post to Introducing AEAP. The flagship post explains what the protocol is and why we published it. This post is the operational companion: what is live, where to install it, and how the pieces fit together.

What shipped

Six public artifacts, all live today:

Artifact	Ecosystem	Status
`@aiyoplane/verify`	npm (Node)	v1.0.1 live
`@aiyoplane/mcp-authz`	GitHub (Node)	Live
`aiyoplane-verify`	PyPI (Python)	v1.0.2 live
`aiyoplane-mcp-authz`	PyPI (Python)	v1.0.1 live
AEAP Receipt Verifier	GitHub Marketplace	v1.0.3 live
`brew install aiyoplane/tap/aiyo`	Homebrew (macOS)	Live

Plus the public source repositories: aiyoplane/aeap, aiyoplane/verify, aiyoplane/verify-python, aiyoplane/mcp-authz, aiyoplane/mcp-authz-python, aiyoplane/verify-receipt-action, aiyoplane/homebrew-tap.

Why two independent language implementations

The architectural choice that matters most about this ecosystem is also the quietest: we built two reference implementations rather than one.

They share no vendored code. The Python verifier is not a port of the Node verifier that imports the same canonicalization library. They are maintained as separate codebases that derive their behavior independently from the AEAP specification. The Python implementation uses the jcs PyPI package for RFC 8785 canonicalization; the Node implementation uses the canonicalize npm package. The Python verifier parses receipts through cryptography + urllib.request; the Node verifier through node:crypto + the native fetch. Different language ecosystems, different standard-library affordances, different implementation idioms.

Why does this matter? Because the whole point of AEAP's protocol thesis is that a receipt issued by one implementation can be verified by any other. If both of our reference implementations were just thin wrappers around a single underlying library, that claim would be unverified. The second-implementation discipline makes it a demonstrated property, not an assertion.

When AEAP v1.0 ships with the Appendix A conformance test vectors, the vectors will be executable against both the Node and Python implementations. Receipts generated by one implementation will verify in the other. Interoperability will be demonstrated through independent artifacts, not assumed.

The verifier packages

Both verifier packages (@aiyoplane/verify and aiyoplane-verify) do the same work: given an Execution Receipt and a JWKS URL, parse the receipt, verify the signature, validate the claims, and return a typed result.

Installation:

npm install @aiyoplane/verify
# or
pip install aiyoplane-verify

Programmatic verification (Python):

from aiyoplane_verify import verify

result = verify(receipt_string, jwks_url="https://api.aiyoplane.com/.well-known/aiyo-jwks.json")
if result["valid"]:
    print(f"ALLOWed. iid={result['claims']['iid']}")
else:
    print(f"Not verified: {result['code']}")

CLI verification (both ecosystems):

# Node:
npx @aiyoplane/verify receipt.txt

# Python:
aiyo-verify receipt.txt

# macOS Homebrew:
brew install aiyoplane/tap/aiyo
aiyo verify receipt.txt

All three paths produce the same verdict for the same receipt. That is the second-implementation claim in operational form.

The Composition Boundary SDKs

The mcp-authz packages are different — they are not verifiers; they are Composition Boundary adapters. They install the AEAP Runtime Decision Point as a decorator / wrapper at a specific Composition Boundary: the Model Context Protocol tool-invocation point.

Idiomatic usage (Python):

from aiyoplane_mcp_authz import create_aiyo_mcp_authz, create_local_rdp

policy = {
    "rules": [
        {"action_type": "deploy", "action_target": "production", "effect": "allow"},
        {"action_type": "payment", "amount_max": 1000, "effect": "allow"},
        {"action_type": "refund", "effect": "escalate"},
    ]
}

authz = create_aiyo_mcp_authz(
    rdp=create_local_rdp(policy),
    tool_config={
        "deploy_to_production": {"aiyo_gated": True, "action": {"type": "deploy", "target": "production"}},
    },
)

@authz.wrap("deploy_to_production")
async def deploy(args, ctx):
    # Runs only if the RDP returned ALLOW.
    # ctx.receipt is the verified Execution Receipt.
    return await actually_deploy(args)

Idiomatic usage (Node) mirrors the same shape. The decorator pattern is the Composition Boundary primitive from the AEAP specification §9 realized in the language idiom of each ecosystem.

Importantly, both packages run the RDP locally for development (the LocalRdp provider) and against a hosted RDP for production (the HostedRdp provider). Switching between them is a one-line configuration change. The receipt format is identical in both cases.

The GitHub Marketplace Action

The AEAP Receipt Verifier (source at aiyoplane/verify-receipt-action) is where the portable-receipt property becomes operationally obvious. A GitHub Actions workflow can verify an Execution Receipt that was issued somewhere else — by Aiyo's hosted RDP, by an enterprise's internal RDP, by any AEAP-conformant issuer — and gate the workflow on the verification result.

Minimum usage:

- name: Verify AEAP execution receipt
  uses: aiyoplane/verify-receipt-action@v1
  with:
    receipt: ${{ secrets.AIYO_RECEIPT }}

Full usage with deploy gating:

- name: Verify AEAP execution receipt
  id: verify
  uses: aiyoplane/verify-receipt-action@v1
  with:
    receipt: ${{ github.event.inputs.aiyo-receipt }}

- name: Deploy (only if receipt is authentic AND verdict is ALLOW)
  if: steps.verify.outputs.verified == 'true' && steps.verify.outputs.verdict == 'ALLOW'
  run: ./deploy.sh

Notice the two gates: verified == 'true' AND verdict == 'ALLOW'. These are separate claims. A receipt may be cryptographically authentic (verified == true) while carrying a non-ALLOW verdict — ESCALATE or BLOCK. The Action surfaces both outputs separately so workflow authors can gate correctly. See the Action's README for the complete security contract and the full output taxonomy.

The Action is a composite action — a thin wrapper that invokes a pinned version of @aiyoplane/verify inside the GitHub Actions runner. There is no bundled JavaScript, no Docker image, no custom build step. The Action is an ecosystem adapter that distributes the canonical verifier primitive into a specific runtime. The verifier does the work; the Action brings it to a GitHub workflow.

The Homebrew distribution

For macOS developers who want AEAP receipt verification at the command line, the Aiyoplane Homebrew tap ships the verifier CLI:

brew tap aiyoplane/tap
brew install aiyo

# Then:
aiyo verify receipt.txt
aiyo verify --json receipt.txt | jq .

The underlying tool is the same Node verifier that lives on npm; the Homebrew path is for environments where brew is the preferred installation surface.

The repositories

Every published package has its source available in the aiyoplane GitHub organization:

aiyoplane/aeap — the AEAP specification itself, CC BY 4.0 for prose and Apache 2.0 for test vectors
aiyoplane/verify — Node verifier source
aiyoplane/verify-python — Python verifier source
aiyoplane/mcp-authz — Node MCP Composition Boundary SDK
aiyoplane/mcp-authz-python — Python MCP Composition Boundary SDK
aiyoplane/verify-receipt-action — GitHub Marketplace Action source
aiyoplane/homebrew-tap — Homebrew formula

Everything Apache 2.0. Issues, pull requests, and discussion welcomed on each repository.

What's coming next

The ecosystem will grow in the direction of adding more Composition Boundary adapters, not more re-implementations of the verifier. Specifically, forthcoming in the near term:

LangChain Composition Boundary adapter — thin wrapper around @aiyoplane/mcp-authz / aiyoplane-mcp-authz that installs the RDP at LangChain's tool-invocation point. Published as @aiyoplane/langchain on npm and aiyoplane-langchain on PyPI. The pattern is intentionally minimal: the adapter is distribution of the canonical primitive into a specific framework, not a new product with its own feature backlog.
Appendix A conformance test vectors — the gating artifact for AEAP v1.0. When both reference implementations pass the vectors identically, the specification promotes from v0.9.1-DRAFT to v1.0.0.
Additional framework ecosystem adapters on the LangGraph / CrewAI / AutoGen / LlamaIndex pattern, each kept similarly thin.

Longer-term, we are actively looking for ecosystem partners. If your use case involves settlement-verified authorization, framework-level Composition Boundary integration, or a rail integration that produces evidence an AEAP RDP would consume, we would like to talk.

How to install, verify, and contribute

If you want to use AEAP receipts in a workflow today:

Add the GitHub Action to a workflow: uses: aiyoplane/verify-receipt-action@v1
Install the Node verifier: npm install @aiyoplane/verify or npx @aiyoplane/verify receipt.txt
Install the Python verifier: pip install aiyoplane-verify
Install the CLI on macOS: brew install aiyoplane/tap/aiyo

If you want to compose AEAP into an MCP server:

Install the Node adapter: npm install @aiyoplane/mcp-authz
Install the Python adapter: pip install aiyoplane-mcp-authz
Read the README on either package for the @authz.wrap() pattern

If you want to read the specification:

github.com/aiyoplane/aeap
Companion flagship post: Introducing AEAP

If you want to contribute:

File issues or PRs on any of the public repositories
Email info@aiyoplane.com for private discussion, security concerns, or partnership exploration
Independent AEAP implementations are welcomed under the same conformance criteria as our reference implementations; no coordination with Aiyoplane is required beyond tracking the test vector artifact as it evolves

Verify First. Execute Second.

The ecosystem is live. The specification is public. The receipts are portable. The verifiers run offline. The authority of AEAP will be established by adoption, interoperability, and the collective practice of the implementing ecosystem — not by anyone's permission.

If you build consequential execution infrastructure for autonomous systems, the AEAP ecosystem is ready for you to adopt, extend, and contribute to today.