> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wipe.me/llms.txt
> Use this file to discover all available pages before exploring further.
# Agent to agent
> Transfer credentials and private artifacts between agents working on different machines without copying plaintext through orchestration messages.
You supervise two agents working in separate remote environments. One provisions
infrastructure or produces a private artifact; the other needs that result to deploy
or configure a service.
Instead of copying plaintext through task messages, queues, traces, or a shared
orchestrator, the producing environment encrypts it with Wipe.me. The agents exchange
only a one-time private link. On the destination machine, `wipeme` consumes the link
directly into the file, environment, or process that needs the value.
## How the handoff works
1. You assign related work to agents on two remote machines or runners.
2. The producing agent asks `wipeme` to encrypt a generated credential, command
output, or approved file.
3. The private link travels through the task orchestrator, agent message, queue, or a
human relay—not the plaintext.
4. The consuming agent passes that link to `wipeme` on the destination machine.
5. Wipe.me writes or injects the decrypted value locally without returning it to the
consuming model.
An unopened automatic private link is a bearer credential. Restrict which task,
worker, and logs can receive it. For a less-trusted orchestration channel, use Custom
mode and provide the passphrase to the destination through a separate approved
source.
## Pass a kubeconfig from Terraform to a deployment agent
You ask an infrastructure agent in a Terraform workspace to create a new Kubernetes
cluster. Terraform produces a kubeconfig on the provisioning runner. A second agent
on a deployment runner needs that file to install your application with `kubectl` or
Helm.
> **Infrastructure agent:** Encrypt the generated kubeconfig as a Wipe.me attachment
> and send only the private link to the deployment task. Do not display the file.
> **Deployment agent:** Consume the kubeconfig attachment into the approved private
> directory, use its path for the initial Helm deployment, and do not print or
> summarize its contents.
On the provisioning runner, the [Wipe.me MCP server](/developer-tools/mcp-server)
uses `create_from_files` to encrypt the kubeconfig. The orchestrator passes the link
to the deployment task. There, `consume_into_files` creates a mode-`0700` directory
and writes the kubeconfig without returning its bytes to either model.
The deployment tool receives the local file path. After the installation and
validation steps, the destination environment removes its copy according to the
cluster-access policy.
## Pass a generated database password to an application agent
A database agent on an administration runner creates a PostgreSQL role for a new
application. An application agent on another server needs the same password as
`DATABASE_PASSWORD` to configure and start the service.
> **Database agent:** Generate a password with Wipe.me, inject it into the approved
> PostgreSQL role-creation process, and send the resulting private link to the
> application deployment task.
> **Application agent:** Consume the first block into `DATABASE_PASSWORD` in the
> approved application environment file. Start the service without displaying the
> value.
On the source runner, `generate_secret_into_process_env` generates one password,
uses it in the approved PostgreSQL command, and releases the private link only after
role creation succeeds. On the destination server, `consume_into_env_file` writes
that same password into a mode-`0600` environment file.
Neither model receives the password. The database role and application receive the
same generated value, while the orchestration history contains only the temporary
link and non-secret status.
## Move a renewed TLS certificate to an edge agent
A certificate-renewal agent obtains a new certificate and private key on a protected
certificate host. A separate edge agent must install them on an Nginx gateway.
> **Certificate agent:** Encrypt the renewed certificate and private-key files with
> Wipe.me and send the private link to the edge deployment task. Do not print either
> file.
> **Edge agent:** Consume both attachments into the approved certificate directory,
> validate the Nginx configuration, reload Nginx, and keep the private key out of
> command output.
The source environment uses `create_from_files`; the edge environment uses
`consume_into_files`. Wipe.me preserves the attachments as encrypted content during
the transfer, while the agents handle only the file paths and link. Source and
destination retention remain controlled by the certificate-management policy.
Wipe.me reduces plaintext in agent and orchestration records. It does not replace
certificate automation, filesystem permissions, key rotation, or access controls on
either remote machine.
## Choose how each side runs `wipeme`
Install the same Wipe.me CLI package and `wipeme` executable in both remote
environments. The two sides do not have to use the same interface.
| Agent environment | How to run `wipeme` |
| ------------------------------------------------ | ------------------------------------------------------------------- |
| A compatible agent host with MCP support | Start `wipeme mcp` and use structured creation or consumption tools |
| An agent operating through SSH or a remote shell | Run ordinary `wipeme` CLI commands on that machine |
| A build or deployment runner | Invoke ordinary `wipeme` CLI commands inside the protected job |
For example, a source-side MCP tool can create the link while a destination-side CI
job consumes it with the ordinary CLI. Both modes use the same encryption and
one-time message format.
Use structured Wipe.me tools in compatible remote agent environments.
Use Wipe.me in remote shells, build runners, and deployment jobs.
## Keep the transfer reliable
* Use one consuming worker. Competing workers must not race to retrieve the same
one-time link.
* Do not automatically retry retrieval after the remote message has been claimed.
* Persist recovery information only where the CLI or MCP workflow explicitly
supports a protected retry.
* Use short expiry and narrowly scoped credentials.
* Keep private links out of broad event streams, diagnostic output, and shared agent
memory.
* Trust both endpoint tools: after decryption, they control how the credential or
file is stored, transmitted, and logged.