The sealed handoff between agents.
Send files, context or secrets from one AI agent to another, across machines, teams or companies. End-to-end encrypted, opened once, then deleted.
You’re on the list. We’ll email when early access opens.
Not launched yet. Early access is a waitlist today; the API and MCP server on this page are what we’re building.
Set up in one step
No config files to edit. Pick whichever is easiest; each one signs you in through the browser and connects sealb.in to the agents it finds.
Planned for launch. Early access members get it first.
Guides for your agent
Pick your agent. One command installs everything; after that it’s just /seal and /open.
npx sealb init --agent claude-code
/seal ./context.tar /open https://sealb.in/s/k7Qx9pL2#key=…
Installs the skill and the /seal and /open commands. The first time you seal something, it asks you to sign in through the browser. Planned for launch.
How it works
Nothing lands in chat history, prompt logs or a gist that lives forever, and you don’t write glue code to move it.
- 1
Seal
The sending agent encrypts the blob locally and uploads only ciphertext, with burn-after-read by default, or a TTL, and an optional password.
- 2
Share the link
Pass the link to the other agent, on any machine. The key in the link never reaches our servers.
- 3
Open once
The receiving agent fetches the ciphertext and decrypts it on its side with the key from the link.
- 4
Gone
After the first read, or when the TTL runs out, the ciphertext is deleted. The link returns 410.
What it saves you
No secrets left behind
Tokens and keys stop showing up in Slack history, prompt logs and old gists. After one read there’s nothing left to leak or rotate.
Context windows stay free
Hand over megabytes of diffs and logs without pasting them into a prompt. The receiver reads an index first and only pulls in what the task needs, so you spend fewer tokens.
No glue code to maintain
One command, two MCP tools, or the skill. No upload scripts, buckets or signed URLs to manage between agents.
Nothing to clean up
Every handoff expires or burns on its own. No stale files in storage, no cron jobs to delete them, no “who still has access to this?”
Easier security reviews
We only ever hold ciphertext, the code is open source, and you can self-host. That’s a short answer when someone asks where your agents send data.
Free to start
The free tier covers one developer’s daily agent work. Pay only when your agents run in CI or production at volume.
Why agents need it
Claude Code to Codex
Hand off a large context bundle (diffs, notes, file trees) without pasting it into a prompt that can’t hold it. Codex opens one link, gets the files on disk, and reads only what the task needs.
A one-time credential for CI
Pass a token to a CI job on another machine as a burn-after-read link. The job reads it once; anyone who finds the link in a log later gets a 410.
A log for the reviewer agent
Share a build log with a reviewer agent on another machine, on a short TTL, instead of a public paste that stays indexed for years.
One command, or two MCP tools
At launch, sealb.in will ship a CLI that any agent with a shell can run, and an MCP server with two tools, seal and open. Both encrypt on your machine. A REST API with API keys will cover everything else.
Inside Claude Code, Codex and other agents it’s just a slash command: /seal ./context.tar to send, /open <link> to receive. Every seal burns after the first read unless you set a TTL.
Opening a seal won’t fill the receiver’s context window. open writes the contents to disk and returns only the path, size and file list. The agent then reads the files it needs, the same way it reads any repo.
# burns after the first read by default $ npx sealb seal ./context.tar $ git diff | npx sealb seal --ttl 1h # or keep it readable for an hour $ npx sealb seal ./deploy.env --password "$HANDOFF_PW" # receiving agent $ npx sealb open "https://sealb.in/s/k7Qx9pL2#key=Yt3v…" > context.tar $ npx sealb open "$LINK" --password "$HANDOFF_PW" > deploy.env
{
"mcpServers": {
"sealbin": {
"command": "npx",
"args": ["-y", "@sealbin/mcp"],
"env": { "SEALB_API_KEY": "sk_live_…" }
}
}
}
// request seal({ "content": "<context bundle>", "ttl": "1h", "password": "optional" }) // result { "url": "https://sealb.in/s/k7Qx9pL2#key=Yt3v…" } // receiving agent: lands on disk, not in context open({ "url": "…", "to": "./handoff/" }) { "path": "./handoff/", "bytes": 18842, "files": ["NOTES.md", "diff.patch", "tree.txt"] }
Or install the agent skill
We plan to ship a skill for Claude Code and other agents that support skills. It teaches the agent the CLI, so it knows when to seal, which flags to use, and how to open a link it receives.
On open, the skill unpacks the handoff into a folder of small markdown files, with an index that links to the rest. The agent reads the index first and opens a file only when the task needs it, so a large handoff costs a few hundred tokens up front.
memory/handoff-k7Qx9pL2/
├── INDEX.md read first: summary + links
├── goal.md
├── decisions.md
├── open-questions.md
└── files/
├── diff.patch.md
└── test-log.md
Sealed conversations
Agents don’t just hand off once; they go back and forth. Pair two agents once with a short code or QR, like signing in to Netflix on a TV, then they send and reply. Every message is end-to-end encrypted with a fresh key and burns after it’s read, so there’s no chat history to leak.
Much simpler than A2A: no agent cards, no HTTP server to run, no task protocol. If an agent can run one command, it can talk.
Planned after launch.
Coming next
Launch covers seal, open, burn, the CLI, the skill and MCP. These follow, in roughly this order. Tell us which you need first when you join.
Agent inboxes
Seal straight to an address like reviewer@owlpost.to, so nobody copies links between machines. Runs on Owlpost.
/seal ./build.log --to reviewer@owlpost.toLocked to the recipient
Each agent gets its own key pair, so only the intended agent can decrypt. A leaked link or transcript is useless to anyone else.
/seal ./deploy.env --to ci-runnerPairing codes and QR
Pair two agents like a TV: the receiver shows a short code or QR, you type or scan it, and they agree on a key directly (PAKE).
/receive → 4F7-K2QPeek before opening
See the verified sender, file list and size without using up the read. Files are checked against the signed preview before release.
/peek 1Receipts, wait and replies
Know when it was opened, block until it is, and reply in the same thread.
sealb seal ./task.md --to coder --waitOptional local scanners
ClamAV and YARA for malware, promptdecode for hidden-text prompt injection. All optional, all on your machine.
sealb config scanners clamav,yara,promptdecodeAn open handoff format
A published spec for the link format, burn rules and the INDEX.md handoff structure, so anyone can build compatible clients and servers.
Open source. Pay for hosting if you want it.
The CLI, the skill, the MCP server, the encryption library and the server will all be open source under Apache-2.0. The hosted service runs on Cloudflare’s network. You pay per agent, not per seal, so normal use never runs into a meter.
Planned pricing. Numbers may change before launch.
Free
For one developer trying it out.
- 1,000 seals a month during launch, 4× the usual 250
- Up to 3 agents
- Up to 5 MB per seal, TTL up to 24 hours
- Burn-after-read and passwords
- CLI, skill, MCP server, REST API
Pro
For a developer or small team running agents every day.
- Up to 10 agents
- Unlimited seals, fair use
- Up to 100 MB per seal, TTL up to 30 days
- API keys scoped per agent
- Audit log of seal and open events, metadata only
Team
For teams with agents in CI and production.
- Everything in Pro, up to 50 agents
- Links on your own domain via CNAME, TLS handled
- Sender policies and roles
- One year of audit history
- Choice of storage region
Self-host
For data that can’t leave your network.
- The same server, deployed to your own Cloudflare account with one command
- No limits beyond your own storage
- Point /seal, /open and the CLI at your URL
- Community support on GitHub
Enterprise. SSO and SCIM, a DPA, region guarantees, an SLA, longer audit retention and direct support. Talk to us.
Agent inboxes and the rest of Coming next will be included in paid plans when they ship. Inbox delivery will include 50,000 deliveries a month on Pro and 250,000 on Team, then $0.50 per extra 1,000. Large attachments are billed by size.
Security questions
What can sealb.in’s servers see?
They see ciphertext, its size, when it expires, whether it has been read, and which API key sealed it.
They never see the plaintext or the key. The key sits in the link’s #fragment, and HTTP clients don’t send fragments in requests. One caveat: if an agent writes the full link into a log, the key is in that log too.
What happens when a link expires?
The ciphertext is deleted and the link returns 410 Gone. There’s no recovery, including by us; we never had the key.
How do I know the client really encrypts before upload?
The CLI, MCP server and client library will be open source, so you can read the encryption code, build it yourself, or watch the traffic and confirm only ciphertext leaves your machine. With a custom domain or self-hosting, links never mention sealb.in at all.
What does a password add?
With a password set, the link alone can’t decrypt anything. The receiver needs both, so send the password through a different channel, such as an environment variable or secret store the receiving agent already has.
The password is combined with the #key on the client. It’s never sent to sealb.in, so we can’t reset it. A wrong password doesn’t count as a read and doesn’t burn the link.
Can someone send my agent malware or a prompt injection?
At launch, your agent only opens links you or your own agents handed it. Seals are end-to-end encrypted, so we can’t scan them on our servers. The skill opens them into a folder marked as untrusted data and never runs anything from it. Optional local scanners are on the Coming next list.
What if the receiving agent crashes halfway through?
The same agent gets a 60-second window to read again, so a crash or retry doesn’t lose the handoff. After that, or once a download completes, the seal is gone for good.
Does the key end up in my agent’s transcript?
It can. Claude Code, Codex and others save tool calls, so a link with its #key may be written to disk. Burn-after-read limits the damage: once the seal is opened, the key unlocks nothing. Seals locked to the recipient, on the Coming next list, remove this risk completely.
How is this different from A2A?
A2A is a full protocol: each agent publishes an agent card, runs an HTTP server and speaks a task API. sealb.in needs none of that. Any agent that can run one command can seal, open and, later, talk, with end-to-end encryption built in. Use A2A to orchestrate agent platforms; use sealb.in when two agents just need to pass something securely.
Two agents open a burn-after-read link at the same moment. Who gets it?
Exactly one. The first read claims and deletes the ciphertext in a single atomic step. Every other request, however close in time, gets 410 Gone.