Overview

What is Zephr

Zephr is a service that lets two independent processes hand off a credential exactly once. The sender encrypts locally, the recipient decrypts locally, and the server never sees plaintext.

Zephr is built for the moment a credential has to move between AI agents, services, or people, without creating shared infrastructure or permanent storage.

Why Zephr

When a credential moves between independent processes today, it leaks into places that persist: prompt contexts, orchestrator logs, environment variables, chat threads. It ends up in more places than it needed to.

Zephr replaces that pattern with a one-time link. The sender encrypts locally, gets a link, and passes it on. The recipient opens it once. The record is gone.

Who It's For

One process calls createSecret, receives a one-time link, and passes that link through any channel (a message queue, task payload, or API response) to a downstream process. The receiving process calls retrieveSecret to consume it. The credential never lives in shared state between the two processes. No broker, no queue, no shared infrastructure. Just a link.

Human workflows follow the same model at human speed. Instead of emailing an API key to a colleague or posting credentials into a chat thread, you send a link, and the record is deleted from the server after the recipient opens it. The recipient sees the credential once, and then it is gone. The security properties are identical whether the consumer is an AI agent or a person. The protocol does not distinguish.

Zephr is built for teams and systems that need credentials to move cleanly and disappear.

• Agent orchestrators moving credentials between tools and workers
• Platform teams wiring secrets through CI/CD and automated deployments
• Security teams who need auditable evidence of secret handoffs
• Developers sharing API keys across environments and collaborators

Need higher volume, longer expiry, or audit trails? Sign in or see pricing.

How It Works

Encryption and decryption run entirely in the calling process, using the browser's native Web Crypto API in JavaScript environments or Python's cryptography library in Python. The client generates a 256-bit key and a unique initialization vector (IV), encrypts the plaintext using AES-GCM-256, and sends only the ciphertext and IV to the server. The key never reaches the server.

In standard mode, the one-time link encodes the key in the URL fragment. As defined in RFC 3986 §3.5, fragment identifiers are not included in HTTP requests to origin servers. The server receives only the request path, never the fragment. This is defined by the URI specification (RFC 3986), not by Zephr.

To use split mode, enable Split URL and Key. The URL and key are delivered through separate channels. The sender transmits each through a channel of their choosing. The recipient enters the key when opening the link. If either channel is compromised, the credential remains protected.

On retrieval, the client recovers the key, fetches the ciphertext, and decrypts it locally. The server deletes the record atomically on the first successful retrieval. A subsequent request for the same identifier returns 410 Gone. A fully compromised Zephr server cannot reconstruct a secret from stored data. For the full threat model, see Security.

Using the Web Interface

Enter your secret into the input field and select an expiry. Click Encrypt & Share. Your browser generates a 256-bit key, encrypts the plaintext using AES-GCM-256 via the Web Crypto API, and sends only the ciphertext to the server. The one-time link encodes the retrieval path and encryption key in the fragment.

Send the link to your recipient. When they open it, their browser fetches the ciphertext, decrypts it on their device, and Zephr deletes the stored record. The link is invalid immediately after retrieval. A second request returns 410 Gone.

CLI & SDKs

The CLI and SDKs implement the same protocol for scripted and automated workflows. The web interface, CLI, and SDK all use the same encryption protocol and wire format. A credential created from the CLI carries the same security properties as one created in the browser.

The CLI installs via npm and reads from stdin, making it composable with standard Unix pipelines. It integrates naturally into shell scripts, CI pipelines, and deployment tooling.

echo "$CREDENTIAL" | npx zephr --expiry 1

The JavaScript SDK ships as an ECMAScript module for Node.js 20 and later, including browser bundles. It exports createSecret and retrieveSecret with a structured error hierarchy and TypeScript declarations. No runtime dependencies beyond the Web Crypto API and the Fetch API.

import { createSecret, retrieveSecret } from 'zephr';

const { fullLink } = await createSecret('my-credential', { expiry: 1 });
const secret = await retrieveSecret(fullLink);

The Python SDK is installable via pip for Python 3.10 and later. It exports create_secret and retrieve_secret with the same structured error hierarchy. No runtime dependencies beyond Python's cryptography library.

from zephr import create_secret, retrieve_secret

result = create_secret("my-credential", expiry_hours=1)
secret = retrieve_secret(result["full_link"])

Full reference documentation, including request and response shapes, error codes, and examples for each surface, is at Documentation.

Requirements

The web interface works in any modern browser with JavaScript enabled: Chrome, Firefox, Safari, Edge, and their derivatives, including mobile browsers on iOS and Android.

The CLI and JavaScript SDK require Node.js 20 or later. The Python SDK requires Python 3.10 or later.

Pricing

Zephr is free to use with no account required. Teams and AI agents with higher volume, longer retention windows, or larger secrets can review plan details and limits at Pricing.