'/%3e%3cpath%20d='M256.00%2051.20L422.03%20460.80L256.00%20288.31L89.97%20460.80Z'%20fill='%231aa7f0'%20opacity='0.7'%20filter='url(%23glow)'/%3e%3cpath%20d='M256.00%2051.20L422.03%20460.80L256.00%20288.31L89.97%20460.80Z'%20fill='url(%23fill)'/%3e%3cg%20clip-path='url(%23shape)'%3e%3cpath%20d='M256.00%2051.20L422.03%20460.80L256.00%20288.31L89.97%20460.80Z'%20fill='none'%20stroke='%2354e4fa'%20stroke-width='24.58'%20stroke-linejoin='miter'%20filter='url(%23rim)'%20opacity='0.9'/%3e%3c/g%3e%3cpath%20d='M256.00%2051.20L422.03%20460.80L256.00%20288.31L89.97%20460.80Z'%20fill='none'%20stroke='%23e2faff'%20stroke-width='3.28'%20stroke-linejoin='miter'%20opacity='0.9'/%3e%3c/svg%3e){kind=small}
Elara
textr
Time
WaveOpen source · Rust · prototype
Agent
Authority.
An agent is not a legal subject. It always acts in the name of a principal, under a cryptographically signed, scope-limited, revocable delegation, checked deterministically by every verifier, with no LLM in the trust path.
What it is
Provable, not claimed.
This is not an attempt to replace A2A, MCP or OAuth. It is the piece those do not cover: a provable answer to “who acted, under whose authority, within what limits, and who is accountable.” Another agent, an API, a bank, eventually an authority: every verifier checks the same signed delegation, the same deterministic way.
01 · Delegate
A principal signs a delegation.
A natural or legal person issues a signed delegation to an agent: which actions, which resources, which counterparties, which time windows, which spending ceiling. Scope-limited by construction, revocable at any time.
02 · Act
The agent signs its own request.
Every request the agent sends is itself signed and carries a nonce plus the intended audience, so a valid signed request for one verifier can never be replayed against another.
03 · Verify
A pure function decides. Not a model.
Signature, time validity, revocation, sub-delegation narrowing and scope matching are deterministic checks in aap-core (Rust). Nothing here is “interpreted.”
04 · Attest
Every decision returns a signed receipt.
Accepted or rejected, the verifier emits a durable, independently checkable record of what was decided and why: an audit trail that does not depend on trusting the agent's log.
Show, don't tell
Watch it decide.
The same aap-core verifier, compiled to WebAssembly, running in this page. Issue a delegation, send a request, watch it get accepted or rejected, replay it, revoke it, with a signed receipt for every decision.
Design decisions
Rust, not TypeScript
A typestate pattern makes unverified and verified delegations different types at compile time. Code that grants authority from an unverified token cannot compile.
Compact JWS over Ed25519 and ECDSA P-256
P-256 exists because phone and laptop secure enclaves can only produce P-256 keys. The algorithm header is checked against the caller's own key before verification runs.
A pure deterministic function
It takes structured input, returns a boolean and touches no external state: auditable, testable, immune to prompt injection.
Status endpoint plus valid_until
A fetchable revoked flag plus a hard expiry. A standard token status list is the real long-term answer; not worth building before the concept is proven.
Sub-delegation only when allowed
A child scope must narrow the parent, never broaden it. This prevents privilege escalation through delegation.
Local keys in v1, behind a signer interface
Swappable for a KMS or HSM later without touching any call site.
Roadmap
- Phase 0: Spec Done
Delegation schema, scope language, verification flow, minimal message set. - Phase 1: Minimal prototype Done
Principal and agent keypairs, issue and sign a delegation, a verifier, a runnable demo. - Phase 2: Robustness Open
Sub-delegation chains and audit receipts are done. A KMS-backed signer and a real registry service are still local or in-memory. - Phase 3: Opening up Open
WASM bindings and browser demo are done. DID/VC resolver and mapping to A2A, OpenID AuthZEN and GNAP are still open.
Questions
Is this production-ready?
No. It is a working prototype with a Rust core, 41 tests in the repository and a browser demo, not a finished standard. The roadmap shows what is done and what is open.
How is this different from OAuth, MCP or A2A?
It does not replace them. AAP is the part they do not cover: a provable answer to who acted, under whose authority, within what limits, and who is accountable.
Does an LLM ever decide whether an action is authorized?
No. Every decision in the verification flow is a deterministic function in aap-core, written in Rust. No model sits in the trust path.