Skip to main content
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 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. 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.

MCP server

Use structured Wipe.me tools in compatible remote agent environments.

Command-line interface

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.