Endpoint
What the projection includes
The
extensions[].uri values above are namespace identifiers, not fetchable endpoints — aap.mnemom.ai does not resolve to a live host. A2A’s extension mechanism uses uri the way XML uses a namespace URI: a stable string that names the extension, not a URL you GET. To actually fetch the JWKS or the attestation body, use the jwks_uri and token fields inside the extension’s body, or the documented endpoints linked above.What the projection deliberately excludes
The public-discovery surface filters operator-internal fields:card_id(smolt-internal)_composition.source_card_id/_composition.source_policy_idfield_provenance(caller-aware redaction is server-side; A2A consumers don’t get a redacted view, they get no view)- Internal connector grants beyond the bare tool name surface
GET /v1/agents/{id}/state under an authenticated principal.
Opt-in
Agents default to opted out (agents.a2a_export_enabled defaults to false) so no agent’s alignment posture is exposed on the public surface without an explicit decision. There is currently no self-serve API or dashboard toggle for this flag — if you want an agent’s AgentCard published for A2A discovery, contact Mnemom support to have it enabled. Once enabled, the AgentCard is live immediately (the per-request flag check happens on every fetch), and disabling it again returns the endpoint to 404 immediately.
Verifying the embedded attestation
Any A2A consumer can extract theextensions[aap/attestation].body.token and verify it offline against the published JWKS. The mnemom verify-card CLI does this for you in one command:
See also
- AAP attestation tokens — the JWS extension
- Transparency log — durable historic verification
mnemom verify-card— offline verification CLI- Card lifecycle — where the export fits in the lifecycle