Your MCP Tool Just Returned a Secret. Did It Need To?

SEAL — Tue, 22 Sep 2026 08:05:27 +0000

“Done. Here's the download link.”

A perfectly ordinary answer from an AI agent. Also the moment a file-access credential can enter the conversation history.

The upload may be encrypted. The link may expire. Neither determines whether the model needed that link in the first place.

For developers building MCP workflows, the tool's return value deserves the same attention as its permissions. A file-sharing tool can complete its job while returning only a reference to the transfer—and delivering the access details directly to a human.

Here is how that handoff works in SEAL, and five places to check before relying on it in your own integration.

Follow the credential

SEAL encrypts files client-side, before upload. Encryption protects the file contents along that path. The share URL and password have their own path through the application.

If those credentials appear in a tool result, the host may put them into model context, retain them in traces, or pass them to another tool. The exact exposure depends on the host and its configuration.

Start your review with two questions:

Where does the file become encrypted?
Where do its access credentials go next?

Answering the first does not answer the second.

Give the model a reference to work with

In SEAL's default MCP handoff mode, the model receives an opaque handle and a receipt. The share URL and password go to the human out-of-band, through the system clipboard or a local file with 0600 permissions in headless environments.

             Create transfer
                    |
                MCP server
                    |
          +---------+---------+
          |                   |
   Handle + receipt     URL + password
          |                   |
        Model                Human

Conceptual routing, not an API response schema.

The model can continue working with the transfer through the documented tools:

Tool	What it does
`seal_share(path, mode?, expire?, max_reads?)`	Creates a transfer; handoff is the default mode.
`seal_list()`	Lists transfers created by this MCP server.
`seal_revoke(handle)`	Revokes a transfer by opaque handle.
`seal_open(url, mode?)`	Takes a URL; do not assume it accepts a handoff handle.

A handle still carries meaning within the tool's authorization context: it can be used to request revocation. The separation concerns the recipient's access credentials, not the removal of all authority from the agent.

Five checks before you trust the handoff

Use a disposable file and a test recipient. The checks below are proposed review steps, not a report of tests performed or additional SEAL features.

1. What actually reaches the model?

Inspect the complete model-visible result, including fields added by the host or your wrapper. Check successful responses and errors.

Look for the secret's value, wherever it appears. A response can omit a field called password and still expose the password inside a debug message.

2. Can another tool retrieve the secret?

Map access to the clipboard or handoff file. A file with restricted permissions may still be readable by another process running as its owner.

If the agent can use a shell or read local files, check whether it can reach the handoff destination. Otherwise, a second tool call may recover what the first deliberately withheld.

3. What happens when delivery fails?

Simulate a failed clipboard or file handoff. Check whether the wrapper “helpfully” prints the link in chat as a fallback.

Review retries, too. A repeated request might create another live transfer; the interface description alone does not establish idempotency. Define the retry behavior your application needs, then verify it.

4. Is forwarding an explicit choice?

SEAL's opt-in forward mode returns the share URL to the model. Its documented constraints are:

TTL ≤ 30 minutes
One read
A required recipient public key
An encrypted audit record for each forward

Verify that invalid requests cannot silently relax these constraints. Check the recipient key and audit outcome. Expiry limits future access; it does not erase copies a recipient has already obtained.

5. Can the agent already read the original?

A hidden share link does not protect plaintext the agent already has permission to read. Review access to the source file and any network tools that could transmit its contents.

Handoff reduces one exposure path. It does not make a compromised host safe or establish that the entire agent environment prevents exfiltration.

A small review with a useful payoff

Before shipping a tool that creates a credential, sketch three destinations: the model response, the human delivery channel, and the logs. Then check which other tools can read each one.

That sketch makes the design concrete. It also exposes an easy-to-miss failure: a secret kept out of the normal response can still appear in a retry, an error, or a fallback.

Which path is hardest to control in your MCP setup: tool results, host traces, or access to the same machine?

Try the pattern

SEAL's MCP integration implements this handoff model for encrypted file sharing. You can explore the MCP integration or read the MCP documentation.

DEV Community: SEAL