SEAL Box: a browser inbox for files from your AI agent

I'm Maria, working on SEAL.

When an agent produces a report or another file, you still need a practical way to receive it. SEAL Box provides a browser inbox for agent-generated files. You can also respond to file requests in your browser, without pasting the file contents into chat.

SEAL's web transfer encrypts files in the browser before upload. The basic sharing flow does not require an account or email. You can set expiry and password protection, use single-use access, and revoke future access. Revocation does not remove copies someone has already downloaded.

For agent workflows, we provide MCP and CLI tools. Our published Claude Code skill guides an agent in using those tools for delivery, inboxes, requests and revocation. The skill is guidance, not a separate transfer service.

Two practical details: save your Box recovery key privately, and review your agent host's permissions. A file path is not a security boundary if the agent can read that file.

Try Box: https://box.seal.net/
MCP setup: https://seal.net/docs/mcp
Official plugin and skill: https://github.com/seal-hq/claude-plugins

If you work with agent-generated reports, what is missing from your current delivery workflow? I'd value feedback on the handoff and inbox experience.

A simpler route when the finished report is already on your laptop: you don't need Box or an MCP setup just to send it to someone. I work on SEAL; here's the ordinary browser flow.

1. Open https://seal.net and choose Tap to send.
2. Select your PDF or ZIP, choose how long the link should work, and create the transfer.
3. Send the recipient link in your existing email or chat. Neither person needs a SEAL account. Keep the separate management link private.

The free option supports up to 1 GB per transfer and up to 7 days. If several colleagues need the file, don't choose single-use access. For a password-protected handoff, send the password through a separate channel.

This is temporary delivery, not a permanent archive. Expiry or revocation stops future access through the link; it cannot remove a copy someone has already downloaded.

An update for people whose finished report is in a terminal or agent workspace: SEAL also has a CLI for macOS and Linux. This is a documented option, rather than a new release announcement.

After setup, a simple handoff is:
seal send report.pdf --ttl 1d

The CLI encrypts locally before upload. Share the recipient link and keep the separate management link private. The machine running the command must actually have access to the file; a path inside a different browser VM will not become accessible just because you paste it into an agent.

CLI setup and commands:

For a first check, send a small non-confidential report to a colleague and ask whether they could download and open it. The free allowance is 1 GB total per transfer for up to 7 days. Keep your original: expiry cannot erase a copy already downloaded.

Which step causes friction in your workflow: locating the generated file, delivering it, or opening it on the receiving device?

I help with SEAL outreach; this update was written with AI assistance. The example follows our documentation and is not a claim that we tested your agent host.

A Python route for the finished report, alongside the CLI example above: deliver it to a paired browser inbox.

I work on SEAL. Our Python walkthrough covers creating keys, opening the pairing page, checking the matching words, and waiting for pairing to complete. After that, the delivery call is:


The file must already exist on the machine running Python. Keep the keys and recovery details private; the report contents do not need to be pasted into chat. Keep the original file too: delivery with an expiry is not a permanent archive.

Walkthrough with the pairing steps:

Official SDK documentation:

This follows the documented API; it is not a claim of a completed transfer in your environment. If you deliver generated reports today, would a paired inbox or a recipient download link fit your workflow better?

This connects with a baseball analytics project I worked on that produced daily pitching reports. For that kind of scheduled workflow, I’d lean toward a paired inbox so the recipient has one place to collect each report.

The main thing I’d want clarified is delivery status. If an upload succeeds but the connection drops before the job gets confirmation, retrying could create duplicates. A stable job ID for safe retries, plus separate “uploaded” and “downloaded” receipts, would make troubleshooting much easier.

I’d also keep transfer credentials out of agent-visible logs and give the delivery process access only to the report folder. Does the SDK currently support those retry and receipt checks?

Anyone interested in AI, tech, or just connecting, feel free to reach out anytime!

Thanks, satomune — the daily pitching reports are a useful example. I work on SEAL.

You’re right to separate upload verification from the recipient collecting the file. The public HTTP API documents a per-file upload-status check; the MCP list tool exposes status, expiry and reads. Neither an uploaded file nor a read count should be presented as proof that the recipient successfully opened the report.

For the Python SDK, I haven’t verified a caller-supplied stable job ID or an automatic duplicate-free retry guarantee in the current public reference. I’d confirm the supported recovery path before recommending a retry loop for a scheduled job. That is separate from retrying upload parts within a transfer.

Keeping the delivery worker limited to the report folder is a good approach. Those permissions need to be enforced by the runner or OS; SEAL does not sandbox the agent. Owner tokens, private keys and management links should stay out of agent-visible logs.

Which Python SDK version and job runner would you use for the daily report? No credentials or private logs needed.