DEV Community

Cover image for SecretBridge: browser-encrypted secret links and Slack handoffs
SecretBridge.app
SecretBridge.app

Posted on Fully Autonomous

SecretBridge: browser-encrypted secret links and Slack handoffs

Disclosure: Published by the SecretBridge.app team. This article was drafted by an AI agent from the project and its documentation, with AI assistance disclosed through DEV's agent-generated content setting. It is a product showcase, not an independent review or security audit.

A credential handoff should not become chat history

A teammate needs an API key. A supplier needs a temporary password. Someone outside your workspace needs to send a credential back to you. Pasting the value into chat is quick, but it leaves another plaintext copy to manage.

SecretBridge.app is a working web app for that short-lived handoff. You can create an encrypted link immediately, without creating an account. Slack and Microsoft Teams integrations add recipient handoffs and receive channels.

A dedicated password or secrets manager remains the right home for ongoing shared credentials. SecretBridge is for delivery, not a replacement vault.

Try the browser flow

Open secretbridge.app and:

  1. Enter the value in the creator.
  2. Choose a short expiry and the fewest reveals the handoff needs.
  3. Share the complete link instead of the value.
  4. If you add a passphrase, send it through a separate channel.

Anonymous link mode encrypts before upload and decrypts in the recipient's browser. Key material travels in the link's URL fragment.

SecretBridge's real desktop creator, with the secret field empty and expiry and reveal controls available.

The screenshot shows the actual app, not a mockup. No secret or reveal link is included. Options expose sender and recipient labels, expiry, reveal limit, an optional passphrase and a receive-channel destination.

The real creator's expanded options, including receive-channel delivery, expiry, reveal limit and an optional passphrase.

The complete URL is sensitive access material. A fragment is not included in an ordinary HTTP request, but the full link is present wherever you paste it. Someone who obtains it can attempt a reveal under the configured controls. A link is not proof of recipient identity.

When the secret needs to arrive in Slack

The Slack handoff uses a SecretBridge receive channel, rather than creating a new Slack conversation:

  1. The recipient runs /secretbridge expect in Slack.
  2. They share the returned random receive ID with the sender.
  3. The sender enters that ID in the browser creator's options and creates the handoff. The recipient gets a Slack notification and follows its reveal or viewer flow.

The sender does not need an address in a public recipient directory. A receive ID permits delivery; it does not grant permission to read secrets. If you share it widely, unwanted deliveries are possible, so expiry and revoke controls matter. Display labels are not independently verified sender identities.

What is free?

Browser links require no account, and receiving is free. Each verified platform user gets one free receive-channel creation per UTC month: that is a creation allowance, not a limit of one received message.

Paid seats add platform sending and more channel creation, subject to safety limits. At publication, pricing is USD 7.99 per user/month or USD 89.91/year, before discounts and tax. Organisation seats are explicitly assigned; personal seats belong to their verified platform user.

Workspace app policies may require administrator approval. A live integration and a public marketplace listing are different things; the setup page explains the currently available install route.

The security boundary matters

Expiry and a reveal limit restrict future access through the service. They cannot make someone forget what they read, erase a screenshot or delete a copy saved in another system. If a credential may have been compromised, rotate it at its actual issuer.

The browser-link flow and native platform modes also have different trust boundaries. Native modes can involve server-side decryption. Do not assume that an encryption feature of Slack or Teams automatically gives a third-party app's entire workflow the same property.

The aim is to reduce sensitive plaintext left in conversation history, with clear limits on what the service can enforce.

Try the browser creator · Slack setup · Security boundaries · Pricing

For feedback: is the receive-ID handoff clear enough for someone outside your workspace, and which step would you simplify? Please use harmless test values; do not post real secrets or working reveal links in comments.

Top comments (0)