Building trust infrastructure for AI agents is not just about issuing credentials. It is about making those credentials impossible to fake, impossible to steal, and impossible to forge.
This week we shipped three security upgrades that address exactly that. Each one closes a specific vulnerability class. Together, they form a significantly more robust trust stack.
Here is what changed, and why it matters — with some plain-language analogies for the non-technical reader.
1. Challenge-Response Holder Binding
The problem it solves
Imagine you have a gym membership card. Someone finds it on the street and uses it to get in. The card is real — the gym issued it legitimately — but the person presenting it is not the person it was issued to.
The same problem exists with digital credentials. A Verifiable Credential is a signed, tamper-proof document. But if a credential ends up in the wrong hands, it could be presented by the wrong party. The credential is genuine. The presenter is not.
This is called a replay attack — using a legitimate credential that belongs to someone else.
What we built
Challenge-Response Holder Binding closes this gap. When an agent wants to prove it owns a credential, the verifier sends a random challenge — a one-time code. The agent must sign that challenge with the private key that corresponds to its DID. The verifier checks the signature.
If the agent cannot produce the correct signature, the credential is rejected — even if the credential itself is completely valid.
The analogy: It is like a bank asking you to sign something in front of them before accepting your ID. The signature proves you are the person the ID belongs to.
What it prevents: Credential replay attacks and agent impersonation.
Live endpoints: /guard/vc/challenge + /guard/vc/verify-binding — 4 end-to-end tests passing.
2. Offline Verifier — @moltrust/verify
The problem it solves
One of MolTrust's core design principles is verifier independence: any counterparty should be able to verify an agent's credentials without calling our API. If verification requires a live connection to our servers, then we become a single point of failure — and a single point of trust.
That is exactly the kind of centralized dependency we are trying to eliminate.
The analogy: A university degree should be verifiable by any employer, without calling the university every time. The diploma has a seal, a signature, a date. A trained eye — or the right verification tool — can confirm it is genuine without contacting the issuer.
What we built
@moltrust/verify is an npm package that verifies MolTrust credentials entirely offline — no API call, no server dependency, no rate limits.
It does four things:
- Resolves the issuer's DID against Base L2 (a public blockchain — no MolTrust server involved)
- Verifies the Ed25519 cryptographic signature on the credential
- Checks the AAE VALIDITY block — is the credential expired? Has it been revoked?
- Evaluates the AAE CONSTRAINTS — is the proposed action within the agent's permitted scope?
12/12 tests passing against Base Mainnet. The package works in any Node.js environment — no MolTrust account, no API key, no network dependency beyond the public blockchain.
What it enables: Any developer can add MolTrust credential verification to their application without a dependency on our infrastructure. The trust is in the cryptography, not in our uptime.
npm: npm install @moltrust/verify
3. Root Key → AWS KMS
The problem it solves
Every trust system has a root key — the private key that signs credentials. Protecting that key is not a nice-to-have. It is the foundation of everything.
The analogy: Think of a notary's official stamp. If someone were to obtain it, they could forge any document. What you really want is a stamp that lives in a vault — one where every use is logged, and the stamp never leaves.
What we built
We migrated both signing stacks — TypeScript and Python — to AWS KMS (Key Management Service) in the eu-central-1 region.
What this means:
- The private key never leaves AWS KMS. It is generated inside hardware security modules (HSMs) and cannot be exported.
- Signing happens inside the vault. We send data to KMS, KMS signs it, we receive the signature. The key itself is never transmitted.
- Every signing operation is logged in AWS CloudTrail. Any use of the root key leaves an immutable audit trail.
- Zero plaintext keys on the server. The signing infrastructure is separated from the application layer.
This is the standard applied by financial institutions and regulated infrastructure for exactly this type of root key protection.
Why These Three Together
Each upgrade closes a different layer of the trust stack:
| Layer | Threat | Upgrade |
|---|---|---|
| Credential presentation | Credential used by wrong agent | Challenge-Response Holder Binding |
| Credential verification | Dependency on MolTrust infrastructure | Offline Verifier @moltrust/verify |
| Credential issuance | Root key integrity | Root Key → AWS KMS |
A trust system is only as strong as its weakest layer. Together, these three upgrades address the credential, the verifier, and the issuer level — the complete chain.
What This Means for Developers
If you are building with @moltrust/sdk or calling the MolTrust API directly:
- Holder binding is available now at
/guard/vc/challengeand/guard/vc/verify-binding. Recommended for any high-value transaction flow. @moltrust/verifyis available on npm. Add it to your verification path to eliminate the MolTrust API as a dependency.- KMS migration is transparent — no changes required on your end.
Start Building
Add agent verification to your API in one line. Express, Hono, Fastify middleware — all supported.
Developer Quickstart →Written by the MolTrust Team (CryptoKRI GmbH, Zurich). Follow @MolTrust on X for updates.