Hermes Secret Drop

I wanted a Hermes agent to be able to receive a credential or a file without either one ever landing in the conversation. Asking for a secret in chat means the secret is now in the chat — in the transcript, in the logs, in whatever the model keeps.

The obvious fix, “just don’t log it”, doesn’t hold up. A chat message is sent to the platform, a tool result is written to the session store before the model sees it, and a request body passes through whatever sits in front of the server. So Hermes Secret Drop takes the secret out of the chat entirely: the agent posts a short-lived link, and the value goes through a web form instead.

Hermes Secret Drop is two self-hosted pieces: a small Node.js broker behind your own HTTPS reverse proxy, and a Hermes plugin with a stock /drop skill command. It works both ways, but the two directions are not mirror images, and the difference is the most important thing to understand about it.

Inbound, you give the agent something. The broker makes a fresh key pair for that one drop, your browser seals what you type or attach to its public key, and the broker — which holds the private key — opens it and hands it to exactly one claim. The agent gets the plaintext, so the model and your model provider see it.

Outbound, the agent gives you something. The broker encrypts it with a one-use key, keeps only the ciphertext, and puts the key in the link’s #fragment. Your browser decrypts it after you type a 3-digit code. The broker can’t read it afterwards, but the plaintext did pass through it to be encrypted. If the agent is relaying a value it already had, that value is in its own tool call and transcript anyway. If it asks the broker to generate one, the value never enters the model at all.

The part I keep coming back to is that the link has no destination field. Not in the command, not in the tool schema — no platform, channel or thread at any depth. A model that cannot express a destination cannot pick the wrong one.

The link goes back into the conversation the request came from, and the plugin checks that against the gateway’s own session context before posting. If it can’t verify it, it refuses (origin_mismatch, origin_unverified, no_origin). It never falls back to a home channel. Only Discord and Telegram are supported, and any other platform is refused by name rather than downgraded. That turned out to be a much better boundary than validating a destination the model supplied.

Every drop is one-shot, and its states only move forward. A second claim gets the same generic “unavailable” as a wrong link, so from the outside a spent drop and a wrong guess look the same.

The link carries a 128-bit capability in its #fragment, which browsers never send to the server, so it never shows up in a request line, an access log or a Referer. The broker keeps only a hash of it. Inbound drops live for 30 minutes by default (1 to 60 can be configured), and three failed decryptions destroy one. On the way out, three wrong codes destroy the payload. Losing a delivery is the deliberate price for not allowing online guessing. The code is a human-presence and anti-preview gate, not authentication: it travels in the same chat as the link. What it does is stop a link unfurler or a virus scanner from opening the drop first. A GET never consumes it.

One trade-off is easy to miss: an opened outbound drop is gone. A page reload costs the secret.

“Not in the chat” is only half an answer, so here is the whole map. The broker keeps everything in memory — no database, no Redis, no analytics, no CDN, no third-party script — and a broker restart destroys every pending drop, because the per-drop keys were never written anywhere. “Destroyed” means removed from an in-memory map and zero-filled on a best-effort basis. Nothing is claimed about swap, core dumps or snapshots.

On the Hermes side, a claimed secret is swapped for a placeholder before the tool result is written to the session store, the search index or the session log. The plaintext is held in gateway memory for at most 15 minutes and put back only into the copy of the request sent to the model provider.

A plain /drop gives the universal form: the person chooses private text or up to five files (42 MiB in total). A request can also describe its own form as a short, closed contract: an ordered list of fields, each with an id, a label and one of five types — text, email, textarea, secret, files. Drop renders it, validates it on both sides, binds it into the encryption, and returns the values keyed by id. Nothing in it is silently repaired; a contract that breaks a rule is refused with a code.

The rule that matters most is that delivery is derived, never chosen. A form with no secret field goes to the model, like every inbound drop. A form with a secret field is forced into a different lane: the whole submission goes to an authorized consumer that runs without the model, and the model gets a receipt with no values in it.

Today no such consumer ships. A form with a secret field is refused before a link is posted. The plugin’s consumer registry is empty on purpose, so a password form fails at mint with secret_consumer_unavailable. Drop doesn’t ask anyone to type a password it could not receive privately. The test suite has a canary consumer, but it is never registered, and it is not vault, BWS or .env integration. The private text lane of the universal link is a different thing. It works today, and what you type there reaches the model, the same as every inbound drop.

Encrypting in the browser only means something if the browser runs the page the broker meant to send. The JavaScript that does the encryption arrives over the same connection as everything else. If an active attacker can rewrite that connection, they can rewrite the code. The swapped page looks the same, but it reads your input before encryption, or seals it to a key the attacker holds. No cipher in that page can help, because whoever wrote the page decides what it encrypts. In the threat model’s own words: authenticated HTTPS is load-bearing; it authenticates the JavaScript that performs the encryption.

There is also a plainer reason: browsers only expose crypto.subtle in a secure context, so on a public host over plain HTTP the page has nothing to encrypt with. Browsers also treat loopback addresses as secure, which is why the local quick start works on 127.0.0.1. That is a developer convenience, not a deployment mode. Drop’s own docs say plain HTTP gives no protection against an active network attacker, and they rule reports against deployments without HTTPS out of scope.

It is not end-to-end encrypted. The broker holds the inbound decryption key by design, and the Hermes host, the broker process and the model are all trusted with the plaintext. Browser-side encryption protects against hops that terminate TLS or log request bodies in front of the broker, not against any of those trusted parties. The claimed value enters the model’s context and goes over the wire to your model provider; if the model echoes it, that echo is stored like any other output. Anything that reads the request after the swap sees it too: an observability hook, NeMo Relay, HERMES_DUMP_REQUESTS=1. None of them should be on for a gateway that handles drops.

It has had no formal or third-party security audit. It was built against a written threat model and has substantial automated test coverage, including RFC 9180 test vectors, but that is not the same thing, and the underlying HPKE library says the same of itself. The consumer boundary is not protection against a malicious plugin on the Hermes host, and exactly-once delivery is not claimed for a future consumer either.

Read these before trusting it with anything that matters:

• Threat model and Limitations, in the README.
• Security policy and scope, including both lifecycles and what deletion is worth.
• The declarative form engine, and why the consumer lane ships closed.