AEAP Security Model & Responsibility Boundaries

Authorization protocols get into trouble the same way reasoning about security always does: a single word — "secure," "authorized," "verified" — gets stretched across questions that are actually distinct, and nobody notices until the questions diverge in production. A receipt that cryptographically verifies does not, by itself, tell you whether the policy was correct. A policy that evaluates to ALLOW does not, by itself, tell you whether the Composition Boundary actually prevented bypass. An enforced ALLOW does not, by itself, tell you whether the action happened once or three times after a crash-and-retry.

With the AEAP specification maturing toward v1.0, we've gone back through the security surface and codified the responsibility boundary — what the protocol guarantees, what it explicitly does not guarantee, and which of its properties belong to the implementation, the Executor, or the Protected Party. This is now AEAP §15 in v0.9.2-DRAFT, and the public-facing version is the new Security model & responsibility boundaries section on aiyoplane.com/trust.

This post walks through the framework.

The four questions

Any security claim about an authorization system decomposes into four distinct questions. They are different questions requiring different controls. Conflating them is where authorization reasoning typically breaks.

Receipt authenticity — Did a legitimate Runtime Decision Point issue this receipt?
Decision integrity — Was the authorization decision sound given the policy and evidence?
Enforcement integrity — Did the Composition Boundary actually enforce the verdict?
Operational accountability — Can an operator later reconstruct what happened, including failures?

AEAP as a specification addresses some of these directly, informs others, and leaves still others to the implementation and the Executor. Taking them one at a time.

1 · Receipt authenticity

AEAP guarantees receipt authenticity via Ed25519 signatures over RFC 8785 JCS-canonicalized bytes, verifiable offline against the Issuer's published JWKS (§7, §8). Any party in possession of a receipt and the JWKS can verify the signature without contacting the Issuer at verification time. The specification also distinguishes six verifier result codes — VERIFIED, VERIFIED_EXPIRED, COMPROMISED_KEY, UNVERIFIABLE, INVALID, INTENT_MISMATCH — so a conformant verifier cannot collapse "the signature mathematically verifies" and "the signing key is still trustworthy for reliance" into a single boolean.

This is the one question AEAP guarantees unconditionally.

2 · Decision integrity

AEAP guarantees deterministic Policy evaluation (§4): the same Policy against the same Intent and the same Evidence Signals must produce the same Verdict. It guarantees fail-closed defaults (§2.2 invariant 5): any ambiguous or indeterminate condition must produce BLOCK, never a silent ALLOW. And it requires the three-component Evidence envelope (§5) — Value / Provenance / Attestation — so every signal a Policy evaluates carries its own trust chain.

What AEAP does not guarantee is policy correctness — whether the author of the Policy expressed the rules they actually intended. A Policy with a decimal-placement error that allows a payment two orders of magnitude larger than intended will produce a deterministic ALLOW, and the receipt will faithfully attest to the evaluation. The authorship of a correct Policy is an operational responsibility that belongs to the Protected Party. We intend to ship operational tooling for policy authoring, review, simulation, and rollback — but that is infrastructure around the protocol, not a protocol guarantee, and we are deliberate about not conflating the two.

3 · Enforcement integrity

AEAP defines the Composition Boundary primitive (§9) and specifies the semantics of the ternary verdict: BLOCK must not execute, unresolved ESCALATE must hold the action pending resolution, ALLOW may permit. The reference adapters we shipped earlier this October — for MCP, LangChain, LangGraph, OpenAI Agents SDK, CrewAI, Microsoft Agent Framework, Google ADK, and the Claude Agent SDK — implement that pattern across the major agent frameworks.

What AEAP cannot guarantee from the specification alone is that the Composition Boundary in a given deployment is the only path to the gated action. If a Protected Party gates a payment through an AEAP-attached boundary but leaves an unauthenticated admin endpoint, a sibling API, or a direct database write that reaches the same consequence, the boundary has been bypassed structurally, not technically. Verifying that enforcement is exhaustive — that the gated action is reachable only through the boundary — is the Executor's responsibility. Our Composition Boundary Adapters give the Executor a correct implementation of the boundary pattern. They do not and cannot verify the Executor's deployment topology around it.

4 · Operational accountability

AEAP defines the Receipt itself (§7) — intent_id, policy_id, policy_version, Evidence Signal digests, Verdict, Issuer, exp — and the optional execution-result lineage-closure callback (§7.5). The intent-to-receipt portion is a protocol guarantee: for every authorization decision the RDP makes, a complete, signed, cryptographically verifiable record exists.

What requires Executor participation is the second half of the trail — the observed outcome of the authorized action. Did it succeed? Fail? Partially complete? AEAP exposes the callback shape for the Executor to report back, but AEAP cannot force an Executor to call it. Complete end-to-end execution lineage, closed by observed outcomes, is cooperative.

The explicitly-named non-guarantees

The honesty move in §15 is naming what AEAP does not guarantee, and attributing each non-guarantee to the responsible party. Four of these are important enough to call out individually.

Exactly-once execution

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. The scenario: Executor receives ALLOW, successfully performs the action, crashes before recording completion, retries. The receipt still verifies — because it is the same valid receipt — and the action can duplicate.

Downstream idempotency is the Executor's responsibility. The standard patterns — idempotency keys tied to intent_id, atomic state transitions, payment-rail-level or database-level deduplication — are mature engineering practice. AEAP does not try to replace them; it stays in its lane and provides the authorization decision, deferring execution semantics to the systems that already know how to handle them.

Pre-expiration revocation of individual receipts

AEAP Core does not provide a mechanism for revoking an individual receipt before its exp. This is a deliberate design choice. Portable offline verification is one of AEAP's most valuable properties — Executors do not need to reach the Issuer at verification time, and the protocol remains available even when the Issuer is not. An online status check on every verification would reverse that property.

Protected Parties who require earlier withdrawal have two patterns available today:

Short-lived receipts with re-evaluation. Issue short exp (seconds to minutes) and require the Executor to re-submit the Intent for a fresh evaluation per sensitive action. This is the recommended pattern for most high-value cases. No protocol change required; it is a Policy configuration choice.
Implementation-specific online status mechanism. An Issuer may expose an online status endpoint that an Executor opts into for specific high-value actions. The Executor explicitly accepts the availability dependency where the use case justifies it, rather than every Executor inheriting it.

We've captured the design surface for a future standardized Receipt Status Profile that would formalize the second pattern — the shape, the typed status codes, the response signing requirements, the executor behavior semantics. It is not scheduled, not in AEAP Core, and will only be built when a design partner surfaces a specific use case the Tier 2 pattern does not fit. Until then, §15 names the boundary cleanly: "AEAP Core does not provide a mechanism for revoking an individual receipt before its expiration. Protected Parties requiring earlier withdrawal MUST use an implementation-specific control."

Policy correctness

Covered above under Decision integrity. AEAP evaluates whatever Policy is authored. Authorship of a correct Policy belongs to the Protected Party. Operational tooling for policy correctness is infrastructure around the protocol, not a protocol guarantee.

Evidence source truthfulness

The three-component Evidence envelope (§5) requires every signal the Policy evaluates to carry a Value, a Provenance, and an Attestation. A conformant AEAP implementation evaluates 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 it describes, or that the Attestation issuer's own key infrastructure is sound. Selecting which Evidence sources to trust — and which attestations to require — is a Protected Party design decision.

Why codifying these matters

Protocols that overclaim end up being quietly disbelieved. A specification that promises "secure authorization" without decomposing the term into verifiable sub-properties forces every security-conscious reader to do the decomposition themselves, in private, with varying results. §15 does that decomposition in public, in the specification text, so there is a single shared vocabulary for reasoning about AEAP's security properties.

It also makes AEAP's responsibility boundary clear to the Executor and the Protected Party. The protocol is one layer. The Executor's deployment topology, downstream idempotency, and operational-maturity practices are another. The Protected Party's policy authorship, Evidence source selection, and operational-change management are a third. §15 names which questions each party answers, which lets each party reason correctly about what they own.

What we're building toward

Codifying the specification is one part of a security story; demonstrating that the implementation operates as the specification requires, under failure and adversarial conditions, is another. There is operational maturity work we're building toward:

Live production key-lifecycle demonstrations. The spec defines the current → rotating-out → retired key lifecycle and the compromise-handling semantics. We intend to exercise them against the hosted RDP as scheduled production events, with the resulting JWKS state changes and COMPROMISED_KEY verifier-code observations published as verifiable artifacts.
Independent external security review. A third-party review covering the AEAP protocol, the hosted RDP implementation, key management, API surface, and the Composition Boundary Adapters, with a public attestation and remediation of any findings.
Adversarial boundary and outage drills. Recorded demonstrations covering live key rotation, simulated compromise, receipt replay attempts, induced RDP outage confirming fail-closed behavior, attempted Composition Boundary bypass, and end-to-end lineage reconstruction.
Published conformance test vectors. Required for the v1.0 stamp. Cross-implementation agreement — the two reference verifiers (@aiyoplane/verify and aiyoplane-verify) producing identical result codes on the same inputs — is the gating property.
Vulnerability disclosure policy. A security.txt at aiyoplane.com, a public disclosure policy, and a CVE process. Standard infrastructure; worth naming.

These are engineering commitments, not shipped items. The Trust page reflects what we've shipped; this post is where we talk about what we're working toward.

What this changes

For developers evaluating AEAP: the shape of the security claim is now the same at every layer. The specification names what it guarantees and what it doesn't. The Trust page names what we've shipped and attributes each capability to the right responsibility holder. This post gives you the context behind both. If you are integrating AEAP into a system where authorization decisions carry weight, you should be able to walk the full chain — spec → implementation → operational demonstration — without having to translate between vocabularies.

For security reviewers and enterprise procurement: the Trust surface plus AEAP §15 is where we expect your questions to land. Where our public artifacts don't yet answer a question you need answered under NDA, email info@aiyoplane.com.

For independent implementers of AEAP: §15 is intentionally scoped to properties that any conformant implementation can be reasoned about against. The non-guarantees apply equally to any AEAP implementation, not just the Aiyoplane hosted RDP. If you build an AEAP implementation, the responsibility boundary described in §15 is yours as well.