QHermes 26: a post-quantum delegation kernel for A2A agent authorization

[Copertino-Research]

Hi everyone,

That's the problem QHermes solves.
We've been building in the A2A space for a while and wanted to share something we think fills a gap the community has been circling around: how do agents prove that a request is within scope, properly authorized, and traceable back to a human root, without calling home to verify it?

What QHermes is

QHermes 26 is a cryptographic authorization kernel. The short version: a human (or organization) issues signed credentials to agents, agents can delegate subsets of those credentials to other agents, and any verifier can check the full chain locally with only the root public key. No server, no registry query, no shared state.

The credential chain is self-contained. It lives in message.metadata. The verifier reads it, checks every hop from root to leaf, and either accepts or rejects. That's it.

Why it's relevant to A2A specifically

We built qhermes-a2a as a dedicated integration layer that covers the three trust points A2A needs:

Signed Agent Cards. The agent's identity, capabilities, and endpoints are signed by the root at registration. Any agent discovering another can verify the card before initiating a connection. This closes the discovery-layer substitution attack. The verifier doesn't need to trust the registry, it checks the signature.

Authorization metadata. A credential chain serialized into message.metadata that any receiver can verify against the root public key. Scope (resource + verb pairs) can only narrow as authority passes down the chain. An agent cannot claim more than it was granted, and this is enforced by the cryptographic structure, not by a policy engine somewhere else.

Session encryption. ML-KEM-768 key encapsulation + ChaCha20-Poly1305 for encrypting message bodies, negotiated in the first exchange.

On revocation

Instead of a revocation registry, credentials carry not_after caveats. A 5-minute execution window expires on its own. No propagation delay, no race condition between a revocation event and a downstream agent that already holds the credential.

Crypto

ML-DSA-65 (FIPS 204) for signatures, ML-KEM-768 (FIPS 203) for key encapsulation. Post-quantum from the ground up. No elliptic curve cryptography.

Python bindings are available for teams not working in Rust.

Repo: https://github.com/Copertino-Corporation/QHermes
Docs: https://qhermes.copertino.world/

Happy to discuss how this fits with what people are building, or go deep on any of the design decisions.

Elio (Copertino)