⚠️ Cryptographic implementations are vetted-dependency wrappers; the library has not undergone external audit. Use in production only after independent review. (Spec §8.)

Use GitHub Security Advisories to report a suspected security regression. Please do not open a public issue.

Advisories let us coordinate with you privately, fix the issue under embargo, and publish a CVE on disclosure.

We aim to respond within 5 business days of the initial advisory and to ship a fix within a 90-day coordinated disclosure window. If the issue is being actively exploited or affects deployed integrations, we will accelerate.

• Cryptographic soundness of mandate verification (ap2-crypto, ap2-sd-jwt, ap2-mandate).
• Selective-disclosure correctness (ap2-sd-jwt disclosure handling, salt entropy reachability, _sd_alg honoring).
• Constraint-engine policy bypass (ap2-mandate::verify, CheckoutMandateChain::verify, PaymentMandateChain::verify).
• A2A data-part validation (ap2-a2a::Ap2Message::extract).
• CLI exit-code semantics (ap2-cli — 0/1/2/3 per spec §13).

These are deployment concerns, not library defects. They are documented in docs/threat-model.md:

• DoS via oversized inputs. serde_json imposes no default size limit; operators must enforce a body cap (e.g. axum::extract::DefaultBodyLimit::max(...)).
• Key generation, rotation, distribution, revocation. The library accepts an Arc<dyn Signer>; it does not store, generate, or rotate keys.
• Transport security. A2A is HTTPS on the wire; TLS / mTLS are the deployer's responsibility.
• Downstream wallet UI, browser sandboxing, mobile-OS TEE integration.

• A minimal reproduction (Rust snippet, fixture, command line, or HTTP request).
• The crate version(s) affected (e.g. ap2-mandate 0.1.0).
• Operating system and Rust toolchain version.
• Expected vs actual behaviour, with a note on the security impact you have in mind.

We credit reporters in the published advisory unless they prefer to remain anonymous. There is no bug-bounty programme for v0.1.x.