Checking · Contacting the Aiyo Runtime Decision Point. ·
aiyo · Live Reference Demo

The Runtime Decision Point, at the MCP tool-call boundary.

@aiyoplane/mcp-authz is Aiyo's reference middleware for composing the Economic Execution Authorization plane above an MCP server. This page runs the middleware live in your browser — real HMAC-SHA256 signing, real receipt verification, real fail-closed on every failure mode. Verify First. Execute Second.

Repo: github.com/aiyoplane/mcp-authz Engineering post: aiyoplane.com/blog/aiyo-mcp-authz License: Apache 2.0

Try a scenario

Each button fires a real MCP-style tool call through the middleware. The RDP evaluates a small policy in-process, issues an execution receipt on ALLOW, and fails closed on DENY. The trace below shows every step.

Execution trace
Idle — pick a scenario
Pick a scenario above to see the intent → RDP decision → receipt → execution → outcome flow.

What this proves

The same primitive — Aiyo's Runtime Decision Point — governs both payment and non-payment actions. Scenarios 2 & 3 are non-payment (deploys). Scenarios 4 & 5 are payments. Both flow through the same authz.wrap(...), produce the same v1. execution receipt, and log the same lineage.

Payment settlement is one possible evidence signal the RDP consumes. It is not the primitive. That's what action-agnostic means, in inspectable code.

Under the hood

Each ALLOW mints a v1.<base64url(payload)>.<hex(hmac_sha256_sig)> receipt using a per-session signing key (256 random bits, generated in your browser). The verifier splits the token, recomputes the HMAC with WebCrypto, timing-safe-compares the signature, and validates the payload claims { iid, cid, mid, exp, iat }.

Byte-for-byte the same format Aiyo's production server-side signer emits. verify-receipt.js · local-rdp.js