End-to-end encryption for AI agent traffic: how MuxAgent keeps your code private

When an AI coding agent runs on your machine, it has access to things that matter: source code, build output, environment variables, file paths, debugging logs, and the natural-language conversations that describe what you are trying to build.

Once you add remote control — the ability to monitor and steer that agent from your phone — all of that content starts moving through a network path. The question every developer should ask at that point is: who else can see it?

MuxAgent’s answer is specific: nobody. The relay routes encrypted traffic between your phone and your machine, but it cannot read the content. Cryptographic keys are generated locally on your devices. The relay never holds plaintext.

That is not a marketing line. It is a design constraint that shapes the entire architecture. This post explains exactly how it works, what the relay can and cannot see, and why this approach is the right baseline for tools that carry AI agent traffic.

Why AI agent traffic is unusually sensitive

Most encrypted messaging discussions focus on chat messages. AI agent traffic is different — and arguably more sensitive — because of what it contains.

A typical agent session may carry:

• Source code from private repositories, including proprietary business logic.
• Natural-language prompts that describe the intent behind changes, sometimes revealing strategy or upcoming features.
• Build and test output that may include stack traces, database connection strings, or error messages containing file paths.
• Plan artifacts that describe the agent’s proposed approach, including which files to touch and why.
• Approval decisions that determine whether code changes proceed — effectively a remote “yes, change my codebase” instruction.

That combination makes agent traffic a high-value target. It is not just conversation. It is operational context about a codebase, carried over a network.

Any remote-control product that treats this traffic with the same casual security as a webhook notification or a log-streaming service is making a mistake. The content justifies end-to-end encryption by default, not as an upgrade.

MuxAgent’s encryption architecture

MuxAgent uses a layered approach: device-to-device key agreement, per-session encryption, and a relay that operates only on encrypted ciphertext.

Key generation is local

When you install the CLI on a machine and pair it with the mobile app, each device generates its own cryptographic key pairs locally. These keys never leave the device.

The relay stores public keys to facilitate pairing and routing. It never sees or stores private keys. That is the foundational boundary: the relay knows enough to connect your devices but not enough to read what they say to each other.

Session key agreement uses X25519

When a session starts between the phone and a paired machine, the devices perform an X25519 key exchange. This is a well-established elliptic-curve Diffie-Hellman protocol that allows two parties to derive a shared secret over a public channel without revealing that secret to anyone observing the channel — including the relay.

X25519 was chosen for the same reasons it is used in Signal, WireGuard, and TLS 1.3: it is fast, well-audited, and has strong security properties against known attacks. The shared secret derived from this exchange is used to establish the symmetric encryption keys for the session.

Session traffic uses ChaCha20-Poly1305

Once the shared secret is established, all session content — prompts, agent responses, plan artifacts, approval decisions, tool output — is encrypted using ChaCha20-Poly1305 AEAD.

ChaCha20-Poly1305 is an authenticated encryption scheme. “Authenticated” means each encrypted message includes a tag that proves it was not tampered with in transit. If a message is modified by anyone between sender and receiver — including the relay — decryption will fail and the tampering will be detected.

This matters for agent traffic specifically because integrity is as important as confidentiality. You do not just need to prevent someone from reading your approval decision. You need to prevent someone from changing a “reject” into an “approve.” Learn more about MuxAgent’s encryption architecture.

What the relay handles

The relay’s job is straightforward: route encrypted messages between paired devices.

To do that, it needs to know a few things:

• Which devices are paired. The relay stores public keys and device identifiers so it can route traffic to the right endpoint.
• Which device should receive a given message. Routing requires knowing source and destination, not content.
• Connection state. The relay needs to know whether a device is currently connected so it can deliver or buffer messages.

That is the extent of the relay’s knowledge. It sees encrypted blobs arrive and forwards them to the right recipient. The content inside those blobs — source code, prompts, plans, approvals — remains opaque.

What the relay cannot see

This is the more important list:

• The relay cannot read the text of your prompts or agent responses.
• The relay cannot read the source code your agent is working on.
• The relay cannot see which files the agent is editing.
• The relay cannot see plan artifacts, review decisions, or approval actions.
• The relay cannot see build output, test results, or debugging logs.
• The relay cannot see the content of tool calls or their results.
• The relay cannot modify messages without detection (authenticated encryption prevents this).

The relay can see metadata necessary for routing: which device sent a message, which device should receive it, and when. It cannot see what the message says.

That is the zero-knowledge property. The relay facilitates communication without participating in the conversation.

Why “zero-knowledge relay” is the right baseline

Some products treat end-to-end encryption as a premium feature or a compliance checkbox. For AI agent traffic, it should be the default architecture.

The relay is a single point of exposure

Any relay or intermediary service that can read content becomes a single point of exposure. If the relay is compromised — through a vulnerability, an insider, or a legal order — every piece of content that passed through it is potentially exposed.

With zero-knowledge design, a compromised relay exposes metadata (who communicated with whom, when) but not content. That is a meaningfully smaller blast radius.

Agent traffic is code-adjacent

Chat messages are sensitive. But agent traffic is one step closer to the production systems and proprietary assets that companies care most about. A leaked agent session could contain the implementation plan for an unreleased feature, a debugging session that reveals a security vulnerability, or CLI output containing secrets.

The closer the content is to code, the higher the bar for confidentiality should be.

Trust must survive vendor changes

Products change. Vendors get acquired, change pricing, change terms, or shut down. If the privacy of your agent sessions depends on a vendor promise rather than a cryptographic guarantee, that privacy is only as durable as the vendor’s current incentives.

End-to-end encryption makes the privacy guarantee structural. Even if the vendor’s priorities change, the relay still cannot read the content because it never had the keys. That is a stronger guarantee than a privacy policy alone.

How this differs from transport encryption alone

It is worth distinguishing end-to-end encryption from transport encryption (TLS), because the two are sometimes conflated.

TLS encrypts data in transit between a client and a server. If you connect to a relay over TLS, the traffic is encrypted between your device and the relay, and between the relay and the other device.

But the relay itself can see the plaintext in between.

That is the critical difference. With TLS-only, the relay is a trusted intermediary. It receives decrypted content, processes it, and re-encrypts it for the next hop. The relay operator can read everything.

With end-to-end encryption, the relay is an untrusted intermediary. It receives encrypted content, forwards it, and never sees the plaintext. The relay operator cannot read the content even if they want to.

For AI agent traffic, the distinction matters enormously. TLS protects against network eavesdroppers. End-to-end encryption protects against the infrastructure itself.

Open source makes the claims verifiable

Encryption claims are only as credible as the ability to verify them.

MuxAgent’s CLI is open source. That means the encryption implementation — key generation, X25519 key exchange, ChaCha20-Poly1305 encryption, message framing — is inspectable. You do not have to trust a claim that “we use end-to-end encryption.” You can read the code that implements it.

This matters for two audiences.

Security-conscious individuals can inspect the implementation before putting real sessions through it. They can verify that keys are generated locally, that the relay only sees ciphertext, and that the cryptographic primitives are used correctly.

Teams with compliance requirements can point to an auditable implementation rather than relying on a vendor’s security whitepaper. The inspection trail is public and permanent, not mediated by an NDA or a sales call.

For a broader discussion of why open source and inspectability are load-bearing properties of remote agent tools, see why trust boundaries matter for remote AI agent control.

Self-hosting moves the infrastructure boundary

Some teams need more than zero-knowledge guarantees. They need to control where the relay infrastructure runs.

MuxAgent supports self-hosting the relay. That means you can run the relay on your own infrastructure, under your own operational policies, with your own incident response procedures.

Self-hosting does not change the encryption model. The relay is still zero-knowledge whether you host it or MuxAgent hosts it. But it does change the operational boundary:

• Data residency. You control where the relay runs geographically.
• Access control. You control who can access the relay’s infrastructure.
• Logging and monitoring. You control what operational telemetry exists.
• Incident response. You control how breaches or outages are handled.

For individual developers and small teams, the hosted relay with zero-knowledge encryption is usually sufficient. For organizations with stricter requirements, self-hosting is the escape hatch that makes adoption possible.

What developers should verify before trusting any remote agent tool

Whether you use MuxAgent or any other tool that provides remote control for coding agents, the evaluation checklist is the same:

1. Can the service provider read your session content? If the answer is anything other than “no, by design,” the architecture does not provide meaningful privacy.

2. Where are cryptographic keys generated? If keys are provisioned centrally rather than generated on your devices, the vendor has (or had) access to them.

3. What cryptographic primitives are used? Look for well-established algorithms with strong audit histories. X25519 and ChaCha20-Poly1305 are good signs. Custom or proprietary cryptography is a red flag.

4. Is the implementation inspectable? Can you read the source code that handles encryption? If not, every claim is taken on faith.

5. What metadata does the relay retain? Even with zero-knowledge content encryption, metadata (who communicated with whom, when, how often) can be sensitive. Understand what exists.

6. Can you self-host the infrastructure? Not everyone needs this, but the option matters for teams with policy constraints.

Those questions apply to any product in this space. The ability to answer them concretely is what separates a real trust model from marketing.

The encryption is invisible when it works

The best outcome of a strong encryption architecture is that you stop thinking about it.

You open the MuxAgent app, see your running sessions, approve a plan, and put the phone back in your pocket. The fact that the approval was encrypted with ChaCha20-Poly1305, transmitted through a zero-knowledge relay, and authenticated with Poly1305 MACs is invisible. The security is structural, not theatrical.

That is the goal. End-to-end encryption should not feel like a feature you opted into. It should feel like the obvious, boring default for any tool that carries your source code across a network.

MuxAgent gets this right by making the encryption automatic, the relay zero-knowledge, the implementation open source, and the self-hosting path available. Those choices add up to a trust model that developers can evaluate concretely instead of accepting on faith.

Your agent sessions carry your code, your reasoning, and your operational decisions. The infrastructure between your phone and your machine should not be able to read any of it. With end-to-end encryption, it cannot.

If you want to go deeper on the broader trust model — relay design, open source, self-hosting, and what it takes to make remote control credible — see why trust boundaries matter for remote AI agent control. If you are ready to set up MuxAgent and see this architecture in action, start with getting started with MuxAgent in five minutes.