How do I pass a secret between two AI agents?

Encrypt it in the sending process, store only the ciphertext, and hand the receiving process a one-time pointer. The pointer should be destroyed on first successful read so a second read fails and a replay is detectable.

Why not use a vault or a shared database to hand over a secret?

A vault is built to give a credential back repeatedly, and a database row is durable by design. For a one-time handoff those are the wrong properties: the secret outlives the handoff, deletion is a promise rather than a guarantee, and backups outlive the delete.

What does one-time retrieval protect against that expiry alone does not?

Expiry bounds how long a secret exists. One-time retrieval bounds how many parties can read it, and makes a second attempt fail visibly, so a replayed pointer is detectable instead of silently served twice.

SLIDINGBOX LLC

How to hand a secret from one agent to another

Passing a credential between two processes without leaving a copy behind, and what the usual approaches leave lying around.

The problem

One process has a secret — an API key, a session token, an intermediate result — and another process needs it once. The two may not share a filesystem, a network, an account, or an operator. The secret should stop existing after it is read.

This is not the same problem as storing a secret. A vault answers "where do I keep my credentials so I can get them back." This is the opposite: a handoff, where the goal is that nobody can get it back.

What people usually do, and what it leaves behind

Environment variables. Fine within one process tree. Between machines or owners, it becomes a copy in a config file, a deploy pipeline, and usually a chat message.
A shared vault. Correct for long-lived credentials. For a one-time handoff it means both parties get accounts, policies, and an audit surface for a secret that should have lived thirty seconds.
A paste service or a link. Convenient, and the content is readable by whoever operates it. Most keep the plaintext long enough to serve it.
A message queue or a database row. Durable by design, which is exactly the wrong property. Deleting it later is a promise, not a guarantee, and backups outlive the delete.

Every one leaves the same question unanswered: did exactly one party read this, and is it gone now?

What one-time delivery actually buys

Two things. The secret stops existing at the moment it is read, so the window in which it can leak is bounded by the reader rather than by a retention policy. And a second read fails, which makes a replay detectable instead of silently succeeding. If a pointer you expected to work returns not-found, someone else already used it — that is information you cannot get from a store that happily serves the same value twice.

Doing it with this service

Encrypt locally, store the ciphertext, hand over the pointer. The service holds ciphertext and never the plaintext or the key.

curl -X POST https://slidingbox.ai/v1/dehydrate \
  -H 'content-type: application/json' \
  -d '{"ciphertext":"<base64url>","iv":"<base64url>","ttl_seconds":300}'

That returns a pointer. The other party retrieves it exactly once:

curl https://slidingbox.ai/v1/hydrate/<pointer> -H 'X-API-Key: <key>'

The item is deleted before the response is sent, so a second retrieval returns not-found whether or not it was paid for. Items expire on their own after 60 to 900 seconds if nobody collects them.

If you would rather not write the encryption yourself, the MCP server does it in your own process and never sends the key anywhere.

What this is not for

Not storage, backup, messaging, or key management. Nothing survives fifteen minutes. It is not appropriate for protected health information or payment card data — see the Acceptable Use Policy.

Try it without an account

curl -X POST https://slidingbox.ai/v1/key

Returns an evaluation key immediately — no signup, no email, no approval step. Send it as X-API-Key on a retrieval to skip payment while the key has allowance left. Storing is free either way.

Read the API documentation View pricing