Show HN: Passwd.page – give agents secrets without pasting them into prompts

Passwd.page launched a zero-knowledge secret-sharing tool that encrypts API keys, files, and credentials in the browser before transmission, with the decryption key stored only in the URL fragment so the server never sees it. The open-source service supports self-destructing links, drag-and-drop file sharing up to 1 MB, and CLI or MCP integration for AI agents to retrieve secrets at runtime without exposing them in prompts. The tool aims to eliminate the security risks of pasting secrets into LLM sessions, hardcoding credentials in configs, or sharing plaintext files through messaging platforms.

Your agents need secrets. Pasting them into prompts gets them logged. Hardcoding them is worse. passwd.page is the zero-knowledge handoff — encrypted on your device, self-destructing, open source. No signup · No app · No subscription · Free & open source New in v3 Shared from laptop, opening on your phone? Scan. Done. No 64-character URL typing. Drag & drop any file up to 1 MB. SSH keys, .env files, certs. Encrypted in your browser before it leaves. Second factor for the paranoid. PBKDF2-hardened, never sent to the server. Even if the link leaks, the secret doesn't. Tell the receiving agent it's an api key vs a postgres url . Eight types. Schema hints for the agent era. For when your agent needs a token right now and never again. Also 15m, 1h, 24h, 7d, 30d. docker compose up -d . Or drop the systemd unit. See SELF HOSTING.md https://github.com/davidfeldi/passwd-page/blob/main/SELF HOSTING.md . The problem Pasting API keys into an LLM session Logged, stored, potentially trained on. Your secret is now someone else's data. Slacking a .env file to a teammate Plaintext, forever searchable, accessible to every admin and compliance tool. Hardcoding secrets in agent configs Plaintext on disk. One git add . away from being public. Giving agents full vault access Over-privileged. Your agent can read every secret, not just the one it needs. How it works AES-256-GCM encryption runs in your browser, your CLI, or your agent. The encryption key never touches our servers. Our server stores encrypted gibberish. The decryption key lives in the URL fragment — never sent to us per the HTTP spec. Even if we get breached, your secrets are safe. The moment the recipient retrieves the secret, it's destroyed on the server. No copies, no backups, no traces. URL structure passwd.page/s/{id} {key} ^^^^^^ ^^^^^ server sees server NEVER sees Use cases Share a database password with your teammate. They open the link, see it once, it's gone. No more "check Slack from 3 months ago." Create a link via browser or CLI. Tell your agent "use the credentials at this URL." The agent retrieves and decrypts at runtime — the secret never enters the prompt. Your agent runs share file on a generated credential — encrypts it without ever reading it into context. You get a self-destructing link. One service hands a short-lived token to another. Encrypted, ephemeral, zero trust. The way machine-to-machine should work. Getting started The simplest way. No install. 1. Go to passwd.page/share /share 2. Paste a secret or drop a file 3. Pick TTL, optional passphrase 4. Copy link or scan the QR For your terminal and scripts. Install verifies checksums curl -fsSL https://passwd.page/install | sh Share a typed secret, 5 min TTL passwd-page create "sk live ..." --type api key --ttl 5m https://passwd.page/s/a3f8 kG7... Retrieve it passwd-page get "https://passwd.page/s/a3f8 kG7..." sk live ... From a file 1 MB max passwd-page create --file .env --type env file MCP tool server. The agent never sees the secret. // claude code settings.json { "mcpServers": { "passwd": { "command": "passwd-mcp" } } } share secret — hand the agent a plaintext value, get back a link. share file — "Encrypt my .env" → agent reads the path, never the contents. retrieve secret — agent fetches + decrypts at runtime. Returns the type so it knows the schema. Why passwd.page Not "trust us" zero knowledge. Mathematically impossible for us to read your secrets. Open source — verify it yourself. One Go binary, embeds the entire frontend. docker run passwd-page and you own your infrastructure. No external dependencies. CLI pipes, MCP tools, REST API. Every interface your workflow needs. echo $SECRET | passwd create No accounts. No master passwords. No subscription. Share a secret, get a link, done. The way it should be. FAQ Paste it, get a link, send the link. passwd.page encrypts the password in your browser with AES-256-GCM and hands you a one-time secret link . The decryption key lives only in the URL fragment and is never sent to the server. The recipient opens it once and the secret self-destructs. A URL that reveals a shared secret a single time, then burns after reading. No copies in Slack, no plaintext in email, nothing left to leak from chat history. Perfect for ephemeral secret sharing — temporary passwords, API keys, database URLs. Yes. Encryption runs on your device and the key never reaches our servers. We only store opaque ciphertext, so we are mathematically unable to read your secrets — even under subpoena or breach. It's open source, so you can verify it yourself. Yes. An MCP tool server share secret , share file , retrieve secret , a CLI, and a REST API let agents hand off short-lived credentials without ever pasting them into a prompt. Email and chat keep secrets in plaintext forever, searchable and accessible to admins and compliance tools. passwd.page secrets are end-to-end encrypted, expire on a timer 5 minutes to 30 days , and can self-destruct on first read. Your agents deserve better. Your teammates deserve better.