Giving out secrets: sealed to each agent's key, the OpenRouter key first

A proposal for Dinis, by security@web-summit.dinis, 3 November 2026. Nothing has been sealed under it yet. It uses only what exists today: the keys page, pki-agent.mjs (pki.sgit.ai's agent tool), admin/tools/seal.mjs and pki.sgit.ai's sealing page.

How sealing works, in four facts

1. Every agent has two key pairs, made in its own session: RSA-OAEP 4096 to receive, ECDSA P-256 to sign. Only the public halves are on the keys page, and each is a QR code on the cards.
2. Sealing encrypts the secret with a fresh AES-256-GCM key and wraps that key to the recipient's RSA key (sgit's hybrid v2 envelope). Only the recipient's private key opens it. The result is an m1. code: a link (https://pki.sgit.ai/m/#m1...) or a QR code (pki.sgit.ai/qr/sealed/v1, up to about 2,300 characters; an OpenRouter key sealed and signed is about 1,500).
3. The sender signs the inner message, over the recipient, the time and the expiry, so a sealed message cannot be re-addressed to someone else. But signing is optional in the tool: an unsigned message opens and reports "not checked". So the rule below makes the check mandatory on the agent's side.
4. No forward secrecy. Anyone who keeps the sealed code and later steals the recipient's private key can open it. That is why every secret given out this way is short-lived and rotated, and why session keys die with their sessions.

The protocol

Sealing (Dinis, or the agent that holds the secret):

1. Pick the recipients from the cards: active keys only. A key marked quiet (no commit by its agent for 48 hours) may belong to a session that is gone; ask before sealing to it.
2. Confirm the fingerprint out of band before the first seal to a new key (WS-106): the person reads their agent's signing fingerprint at the stand-up, or shows its key QR from their own screen. The keys page only says that someone with push access added it.
3. Seal by fingerprint, never by label, signed with the sender's key, with an expiry of 7 days or less:

- in the browser: open the agent's card, Send a secret (pki.sgit.ai/send, the key already filled in), paste the secret, sign in with your key, seal; - or from a session: node pki-agent.mjs seal --to <signing fp> --file <secret file> --expires 7 --qr <agent>.png (never --text: a secret on a command line lands in the shell's history).

Receiving (each agent, every time):

1. node pki-agent.mjs open <link | m1 | qr.png>.
2. Refuse it unless it is signed, and signed by the operator's key (sha256:db7f79fdd87e030a, or a key Dinis names in writing for that secret). An unsigned or wrongly signed "OpenRouter key" is an attack: someone else's key, paid by them, would route every prompt and every vault excerpt through an account they read.
3. Keep it in the session only: an environment variable or a file under ~/.sg-send/ (gitignored, WS-86). Never in the repository, a page, a commit message, a pulse entry or a vault lane.
4. Say what you received, never the value: a commit Agent: <you>, "received the OpenRouter key sealed by sha256:db7f..., expires <date>".

Ending: when the expiry passes, or a session ends, the secret is rotated at its source (the OpenRouter key disabled), not just forgotten.

The OpenRouter key

Recommended: one key per agent, not one key for everyone. OpenRouter can make API keys from a provisioning key, each with its own credit limit, and disable any one of them (its provisioning API). Dinis keeps the provisioning key; it is never sealed to anyone.

Phase 1, today: Dinis makes a capped key per agent that needs one (the agents that build things first: the dev agents, the sgit agent, the conductors), seals each to its agent's fingerprint, 7-day expiry, and hands the sealed link to the person. The gate already refuses OpenRouter key shapes (sk-or-v1-...) anywhere in the repository (admin/build/secrets.cjs).

Where sealed secrets travel

Two modes, both safe for short-lived, capped secrets. Dinis chooses (decision 3 on the PKI page):

1. Handed over: the sealed link or QR code goes from Dinis to the person (on screen at the stand-up, or in a message), and the person passes it to their agent's session. Nothing lands in git. Recommended for phase 1.
2. Published here: a page of sealed QR codes, one per agent (data/sealed/, rendered on this section). Convenient: an agent finds its own secret on the site. The cost: a sealed secret committed to git is in its history forever, readable by anyone who later gets that agent's private key. Acceptable only with three rules the gate would enforce: the recipient is an active key, the message is signed by the operator's key, and it expires within 7 days. Never for vault keys.

Vault keys come last

A vault key is not as disposable as it looks. Archiving a vault does not make its key harmless: anyone who kept the vault's encrypted objects (the sync server, a clone, a backup) and later gets the key reads everything the vault ever held, including the private material it exists for (meetings, contacts). So:

• vault keys go only by hand (mode 1), never published, and only to keys whose fingerprint was confirmed out of band (WS-106);
• "rotating" a vault key means a new vault and moving the live material, and the old vault's objects deleted at the server, not only archived;
• the team vault keys stay sealed to the vault registry key until WS-106 is done (Vaults).

What can go wrong, and what stops it