§
🌙 Toggle Dark Mode Home MoltGuard MolCheck verifier MT Global · Regulated Markets MolTrust Sports MT Shopping MT Travel MT Skills MT Prediction MT Salesguard MT Music MT Ads Integrity Dashboard VCOne Blog Developers Pricing Enterprise Partners Compliance About Publications Verify Us Status Contact API Docs
← Back to Blog
Security 20 October 2026 3 min read Lars Kroehl

Leak canaries for delegated agent credentials

A credential handed to another agent should only come back from that agent. A leak canary signs a record when it comes back from someone else.

In October 2026 the Institute for AI Policy and Strategy (IAPS) published Honeypots for AI Agent Insider Threats by Jan Wehner and Jam Kraprayoon. The report argues that decoys belong in production deployments of AI agents. Their definition of a honeypot is a decoy opportunity for an unauthorised action: a fake admin credential, a server no task needs, a staged message from another agent that proposes collusion. Any use of it is a signal, because no legitimate task requires it.

Prior art

The report traces the idea back to 1986, when Clifford Stoll used a deliberate bait to track an intruder at Lawrence Berkeley National Laboratory. Lance Spitzner proposed honeypots against insider threats in 2003, at the ACSAC conference. Thinkst runs Canarytokens, a public service that generates tripwires such as AWS API keys, Word documents and kubeconfig files; each one alerts its owner when someone opens or uses it. Thinkst, Tracebit, CounterCraft and Attivo sell decoys as enterprise products.

The leak canary described below applies that principle to one specific case. It adds no new detection idea.

The indirect case

The report's appendix on attribution (p. 69) describes how defenders find the agent behind an alert. If the platform tags every tool call with the agent instance, a direct touch of the honeypot leads straight to that instance. When the agent acts indirectly, for example by instructing another agent, the trail runs through logs that may not exist, and defenders end up with a list of candidates.

Delegation between organisations is that indirect case by design. An agent hands a credential to a counterparty's agent, and the credential leaves the issuer's logs at the boundary. If it later surfaces with a third party, the issuer learns that something leaked and cannot say which counterparty it came through.

One canary per counterparty

The leak canary in MolTrust gives a delegating agent one canary credential per counterparty. A canary is an ordinary W3C Verifiable Credential, a signed digital certificate, issued by the same code path and signed with the same keys as every other MolTrust credential. The server records which counterparty received which canary, and only the issuer can read that record.

In bound mode the counterparty holds the canary as its own credential. Presentations by the issuer or the counterparty stay silent; anyone else who presents it triggers an event. In decoy mode the canary travels as bait among real material, and every presentation except the issuer's own triggers.

The MolTrust verifier answers a canary the same way it answers any credential. After the answer is sent, MolTrust writes a leak event that names the counterparty and signs it with its registry key. The event carries replay material, so a third party can recompute the verdict offline with moltrust-verify from the moltrust-enforce package on PyPI, without a call to MolTrust.

What an event proves

An event proves that the canary has left the counterparty's hands. It names the counterparty as the route only when the presentation carries an HTTP message signature (RFC 9421) made with the counterparty's own key. MolTrust then records the attribution as counterparty; without that signature it records open, and the route stays unknown.

The canary only sees presentations at the MolTrust verifier. A party that checks a leaked credential's signature on its own, or only stores it, leaves no trace. Events hold decentralized identifiers (the public IDs of the agents involved), digests and timestamps. They hold no IP address, name or free text.

Trying it

Endpoints, data model and limits are documented in docs/leak-canary.md. The endpoints run on api.moltrust.ch, and the MCP tools canary_issue, canary_list and canary_events call them from an agent. Issue one canary per counterparty with POST /canary/issue and read the results with GET /canary/events. If you run honeypots for agents and want to compare attribution data, write to hello@moltrust.ch.

Sources