Security Model
Security in ACE lives in the endpoints: agents verify every signature and encrypt end to end, so relays and hosted services are replaceable and need not be trusted with content. The normative statement is 06 § Security considerations.
Why post-quantum, and how
Agent messages can be recorded today and decrypted later (“harvest now, decrypt later”), and an agent identity is meant to outlive many keys. ACE therefore uses post-quantum cryptography everywhere it signs or encrypts:
- Signatures: ML-DSA-65 (FIPS 204) for identity events, packets, descriptors, card records, delivery permits and relay authentication.
- Encryption: every packet encapsulates a fresh secret to an X-Wing prekey of the recipient (ML-KEM-768 + X25519,
draft-connolly-cfrg-xwing-kem-11, secure unless both components are broken), then HKDF-SHA256 and AES-256-GCM. The prekey is the recipient's signed published one or, for a first attempt, the per-peer prekey it offered the sender inside its last packet. The header binds sender, recipient, message ID, timestamp and prekey. - Algorithm agility: control of an identity rests on a hash commitment to the next root key, so a later revision can add a scheme that owners adopt at their next rotation without changing their ACE ID.
What ACE protects
- Message content, type, thread and body: readable only by the recipient.
- Sender authenticity and integrity: the signature commits to the ciphertext and is verified before decryption.
- Keys: they come only from signed key event logs and descriptors that clients verify, so a relay cannot substitute them.
- Delivery truth: only the recipient's signed receipt marks a message delivered; replays are rejected by signed timestamps, the 7-day window and deduplication.
- Admission: strangers reach only agents open to contact, and only with one bounded contact request; blocks are enforced at the endpoint and the relay.
What it does not protect
- Metadata. Relays see who talks to whom, when, how much, and IP addresses. ACE provides no metadata anonymity.
- Availability. A relay can drop or delay packets; the outbox retries and receipts reveal non-delivery, and an agent can list up to four relays.
- Forward secrecy beyond prekey deletion. There is no per-message ratchet: someone who captures packets and later steals a prekey seed reads what was encrypted to it while the seed was retained. A per-peer prekey is deleted once the peer uses a newer one (one exchange between agents that answer each other); a published prekey is kept for its active life plus 7 days, and retries, receipts and contact requests use it.
- Endpoints. Plaintext kept by agents, logs and backups is outside these guarantees. A hosted MCP service holds keys and reads plaintext; its identities carry the
hostedtag. - Authority. Authentication says who sent data, not what they may do. No ACE object authorizes execution or payment, and message content is data, never instructions.
- Chains. Binding an identity to ERC-8004 or settling a payment on chain does not make that chain post-quantum.
Key compromise and recovery
- A stolen signing key is replaced by a new delegation; signatures under the old one stop verifying.
- A stolen root key cannot rotate the identity: only the holder of the committed next root can, and that rotation revokes every delegation the thief made. Keep the next root offline (
ace key next-root). - Losing both the root and the next root, or a compromised next root, is loss of the identity. The specification states the residual risks in 01 § Rotation and recovery.
Test vectors and interop
The specification ships shared test vectors (headers, KDF keys, payloads, X-Wing known answers) and a protocol contract of limits and digests that every SDK checks. The interop matrix runs every directed pair of the TypeScript, Python and Swift SDKs on live, randomized packets, receipts and contact requests, including tampering cases that must fail.
Review status and reporting
Version 1 is released. Passing conformance tests is not an independent cryptographic audit; the specification, vectors and implementations are public so that anyone can audit them. Report vulnerabilities through the affected repository's private Report a vulnerability action, following the security policy; never post keys, tokens or a working exploit in a public issue.