Clear boundaries beat vague promises.

Browser-encrypted links

For public links, plaintext encryption and decryption happen in the browser.

• A fresh random seed is generated for each secret.
• Separate reveal-access and content-encryption values are derived from that seed.
• The content uses authenticated AES-256-GCM encryption before upload.
• The compact seed remains in the URL fragment after #, which is not included in ordinary HTTP requests.
• The service stores a hash used to check access, not the seed itself.

Keys, envelopes, and destruction

Each secret has independent content-key material. Service-managed modes wrap that material with tenant-scoped key protection; browser-link modes keep the decrypting capability with the complete link. This limits the effect of a single secret-key exposure instead of relying on one reusable content key.

Expiry, reveal completion, revocation, uninstall handling, and retention sweeps remove secret material according to lifecycle rules. Application logs are designed not to intentionally record secret plaintext or access tokens.

Slack, Teams, and Outlook modes

Collaboration platforms add identity and conversation context, but they do not provide automatic end-to-end encryption for custom app input and cards. A native mode may send plaintext to SecretBridge over TLS so the service can encrypt or reveal it. Protected and enrolled-device modes move capture or decryption into a browser surface.

Transport Layer Security protects data while it moves between a browser, platform, and service. Browser-side encryption additionally protects against application logs, middleware, and server-side components accidentally seeing plaintext—but it cannot protect a compromised endpoint.

Metadata and tenant isolation

SecretBridge still processes information needed to operate: tenant and workspace identifiers, user and conversation coordinates, sender and recipient labels, creation and expiry times, reveal limits, state, and security events. Verified installations resolve to tenant-scoped credentials, policies, metadata, and encryption-key configuration.

Metadata can itself be sensitive. It is retained only for product operation, abuse prevention, support, compliance, and incident investigation as described in the Privacy Policy.

Threats outside the boundary

• Anyone holding a complete unprotected anonymous link can attempt a reveal before it expires or is consumed.
• A recipient can copy, photograph, forward, or otherwise retain a revealed value.
• Malware, hostile browser extensions, screen capture, clipboard managers, and compromised devices can expose plaintext.
• A mistaken recipient, unsafe passphrase channel, or already-compromised collaboration account can defeat the intended handoff.
• URL fragments may remain in browser history and can be read by scripts executing on the same reveal page.

Use the shortest practical expiry and reveal count, add a separately delivered passphrase for higher-risk links, verify recipients out of band when necessary, and rotate any credential that may have been exposed.

Report a security issue

Send a report to the support contact shown in the app marketplace listing with safe reproduction steps, impact, and an approximate time. Do not place working secrets, access tokens, private keys, or another customer's data in the initial report. We will coordinate a safer way to exchange sensitive evidence.