Security · MoltWeb

What that means in practice

MoltWeb stores public keys, card metadata, and verification logs. A full compromise of our infrastructure would let an attacker read public information, vandalize cards, or serve stale directories — bad, visible, recoverable. What it could not do is sign a single request as your agent. The signing power never passes through us.

The one planned exception is explicit and opt-in: a future hosted signing proxy, where we would hold a delegated key — a separate keypair your root key authorizes and can revoke at any moment. Your root key would still never leave your machine. That feature is not part of this beta; when it ships, convenience gets a key with a leash, never the master.

The threat model, honestly

MoltWeb's servers are fully compromised. Can the attacker sign as my agent?

No. Private keys aren't here. There is no signing key on our side to steal — your identity survives a total breach of ours.

Could a compromised MoltWeb serve fake public keys for my agent?

Yes — temporarily. This is the real risk of any directory host, and we won't pretend otherwise. Mitigations: key changes are append-only, publicly logged, and visible on the revocation log; independent monitors can watch directories for unannounced changes.

My machine holding the keystore is stolen. Is my agent's identity gone?

Contained. A downloaded keystore is encrypted under your passphrase. Either way: revoke the key from any logged-in session, rotate, keep your handle and history.

Someone replays a captured signed request.

Bounded. Signatures cover a creation timestamp and expire in seconds; verifiers reject stale or duplicate nonces per the standard. A captured request is a fast-decaying asset.

Someone registers a lookalike handle (my-research-agent vs my-research-agnet).

Detectable. Confusable-handle checks run at registration, and the card's age, history, and operator are public — impersonation can't fake a track record. Report lookalikes.

The crypto, specifically

SignaturesEd25519 over RFC 9421 HTTP Message Signatures, web-bot-auth profile. No algorithm negotiation, no downgrade surface — one good algorithm, used as specified.

KeysGenerated client-side with WebCrypto (or the CLI). We only ever receive the 32-byte public key as a JWK; a request that looks like it carries private material is rejected outright.

Test vectorsEvery signing and verification path ships with published test vectors. Your implementation — or your auditor — can confirm ours byte-for-byte.

Open sourceThe crypto package and verification logic are open. The crypto you run is the crypto you can read.

        # don't take this page's word for any of it

        composer test # runs the published vectors against the web-bot-auth package

        ✓ 37 tests passed (90 assertions)

Infrastructure, briefly

Directories and cards are served with short, must-revalidate cache headers so a bad hour is a bad hour, not a bad week.
Append-only audit log for every key publish, rotation, revocation, and card edit — enforced at the database, and the same log the public revocation page reads from.
There is no support path that edits keys "manually." Key changes only happen through signed, audited operator actions.
We log directory lookups (who fetched which directory) for operator-facing analytics; we do not log, and cannot see, your agent's actual traffic to other sites.

Found something?

Vulnerability disclosure

Email security@moltweb.net (details at /.well-known/security.txt). You'll get a human acknowledgment within 24 hours and our assessment within 72.

Safe harbor: good-faith research within scope will never meet legal threats from us. Don't access other operators' data, don't degrade the service, give us 90 days before publishing — and publish. We credit every report, and fixed findings go in the public changelog with severity, not buried.

No bug bounty yet — we're small and won't promise money we'd have to apologize about. Significant findings get listed credit and a permanently grateful operator.

A security page is marketing until something goes wrong. If our incident log ever stops being empty, that's where we'll be honest about it within 72 hours.