Assume the Net Leaks: Designing Agent Protocols for Untrusted Proxies

Assume the Net Leaks

Assume the net leaks. If a proxy can read it, it will eventually spill it.

That sounds harsh until you remember what sits between an agent and its tools: load balancers with sticky fingers, CDN edges that normalize and rewrite, ad-tech pixels that cross-stitch identities, and observability taps that drink more than they admit. We built a web that runs on intermediaries. We then built agents that speak cleartext semantics atop encrypted pipes, and act surprised when context, secrets, and the very shape of our systems seep through the cracks. The surprise is the problem.

The right stance for agent security is simple: treat every intermediary as untrusted. Not partially trusted. Not trusted-by-config. Untrusted. That means designing protocols and runtimes that expose a minimal surface, use end-to-end protections regardless of who terminates TLS, attest that code is what it claims to be, and operate as if a forensic leak is not a matter of if but when. The good news is you can do all this today without turning your stack into an academic exercise.

The rest of this essay is practical. It lays out what middleboxes actually see, what to encrypt and how, how to run agents you can attest instead of just trust, and the operational posture that makes leaks survivable. There is no magic. There is careful engineering and habits that pay back the first time a proxy misbehaves, or a vendor posts a “we found uninitialized memory” update you wish you could unread.

What Middleboxes Actually Expose

Start with the basics: TLS is not a cloaking device. It protects packets in transit between two endpoints. If a CDN, reverse proxy, API gateway, or traffic mirror sits as one of those endpoints, it sees the decrypted traffic and anything attached to it. That usually includes:

• HTTP method, path, and query parameters if you terminate TLS at the proxy.
• Headers and cookies, often the very place engineers stash metadata they don’t want to touch the body with.
• Response bodies for caching, compression, and transformation.
• Timing, sizes, and sequencing. Even when bodies are opaque, traffic patterns betray behavior.

Proxies do more than pass bytes. They normalize header case, strip hop-by-hop fields, add their own fingerprints, and inject tracing headers and session cookies. They occasionally dump memory. That is not slander; parsing and pooling are hard, and it only takes one edge bug to mix buffers and leak a few stray kilobytes where they do not belong. Those few kilobytes might include prompts, function arguments, partial embeddings, or the names of tools the agent can call. Enough to correlate. Enough to reconstruct behavior.

Ad-tech collectors and analytics scripts make it worse by correlating telemetry across fetches. Separate hosts may be stitched back together with IPs, TLS-session hints, device fingerprints, and header quirks. Send an agent to three tools behind the same ad network and watch the network earn a living by learning the shape of your workflow. Skill provenance leaks this way: not because you said “call Tool X,” but because the request cadence and header mix match a known client.

The agent runtime itself leaks through

• user agent strings (often forgotten in server-to-server contexts),
• Accept-* hints,
• content encodings the runtime negotiates by default,
• and the set, order, and formatting of custom headers your framework adds.

Then there is memory. Proxies and middleboxes terminate and re-encrypt. Workers handle many tenants in the same process, often with a shared allocator, buffers, and pools for performance. Under pressure, rare and painful bugs spill uninitialized memory into someone else’s response or logs. The headline appears, the postmortem lands, everyone apologizes. What matters is what your agent spilled: did an incidental leak expose a bearer token and the full context of a prior request, or did it reveal nothing a careful attacker could use beyond what they already had?

This is not a theoretical complaint. It is routine. It is why “assume the net leaks” is not fatalism; it is an engineering constraint.

One last point on exposure: who your proxy is matters for regulation as much as for attack surface. In a Gulf enterprise with multi-entity structures, traffic often traverses providers in multiple jurisdictions before it settles. That raises questions less about zero-days and more about lawful access, retention, and cross-border controls. In those contexts, designing for untrusted intermediaries doesn’t just harden systems; it simplifies compliance conversations by reducing who can see what, by construction.

End-to-End by Design, Not Slogan

End-to-end encryption is a phrase tossed around at conferences. The trouble is that many agent architectures do the opposite in practice. They terminate TLS at an edge for caching and WAF features, route into a mesh that re-terminates again, and only then pass payloads to an agent runtime. Every hop sees the goods. That may be fine for static assets; it is reckless for agent context and tool credentials.

What does end-to-end mean when you ride on other people’s computers? It means adding a content encryption layer inside your transport. You keep TLS 1.3 with HTTP/2 or HTTP/3 for basic channel security and performance. Then, you encrypt the message body (and all sensitive metadata) with keys that only the agent and its intended peer hold. Any proxy between them can route, buffer, or drop packets. It cannot read or meaningfully modify the message without detection.

Concretely:

• Encrypt at the message layer using a modern authenticated encryption scheme (AEAD). It should supply confidentiality and integrity with a unique nonce per message.
• Use a key exchange that provides forward secrecy and key rotation without ceremony. HPKE is suitable for this pattern and has healthy library support. JOSE/JWE variants can also work if your organization already carries that stack; just be disciplined about algorithms and key management.
• Include replay protection and freshness: sequence numbers, short-lived nonces, and tight expiries.
• Put sensitive metadata inside the encrypted envelope. That includes tool names, chain-of-thought summaries, tool arguments, and any user-provided tokens. Leave only what the proxy must see: a stable path, an opaque content-type, and maybe a minimal routing hint. If something can be in the body, put it there.
• Consider padding to reduce side-channel leakage on message size. Not every message needs constant size padding; rounding to a small set of buckets often gives you 80% of the benefit at lower cost.

Agents do not speak only request-response. They stream via WebSockets or server-sent events. The same rule applies: frame a message format inside the stream where each frame is independently encrypted and authenticated. Proxies can terminate the WebSocket and still not see anything useful.

This pattern changes where you put your WAF. Many teams rely on proxies to inspect bodies for cross-site scripting, injection patterns, and PII. If the body goes dark, your edge loses that visibility. You have two options:

• Move inspection closer to the agent, where it can see decrypted content. That could be a sidecar that runs inside your trust boundary and validates schema, rate limits, and checks for policy violations before forwarding into the agent.
• Publish a narrow metadata schema that rides outside the encrypted payload. Keep it truly minimal and stable. The WAF reads only that schema and enforces coarse controls, not content inspection.

A quick note on DNS and client hello privacy: ECH (Encrypted ClientHello) and DoH/DoQ help reduce what on-path observers and some middleboxes learn from SNI and DNS queries. Where available, use them. Just do not confuse them with end-to-end content protection. They hide routing metadata from on-path observers, not from the proxy that you explicitly talk to.

For multi-agent coordination, avoid accidental disclosure via the orchestrator. When an orchestrator fans out tasks to tools, wrap each tool call in its own message-layer envelope with a key scoped to that tool and task. If a proxy routes for the orchestrator, it sees the hub-and-spoke but not the content. When you need group messaging, look at standards being shaped in the secure messaging world (e.g., MLS) and borrow their concepts: group keys, epochs, and update strategies to limit the blast radius of compromise.

Why not rely on gRPC or another binary protocol to be “less readable”? Binary is not security. Proxies understand gRPC well. Many decompress, normalize, and trace it just as eagerly as HTTP/JSON. The only reliable way to hide semantics from an intermediary is to keep them outside the intermediary’s view.

Finally, keep headers boring. Do not stuff context into X-Whatever headers because they are convenient and easy to debug. Those are precisely the fields that proxies and ad collectors log, mirror, and use for correlation. If you must send a hint for routing or rate limiting, keep it to a short token that your edge can verify as opaque (e.g., a MAC over a small claim set), not a rich string with structured context.

Attested Agents and Tight Runtimes

Encrypting traffic end-to-end reduces what the network learns. It does not constrain what the agent runtime itself does with secrets and context once decrypted. Here you want two properties: isolation and attestation.

Isolation means the agent runs with the least capability necessary, in a narrow sandbox that can only talk to the specific peers it needs, with no ambient authority to read the filesystem, open arbitrary sockets, or spawn unexpected processes. That pushes you toward runtimes with capability-based sandboxes and process-level isolation:

• WebAssembly runtimes with WASI can give you fine-grained hostcalls. Make the set of imported functions small and explicit. No raw filesystem access, no unrestricted network. Provide tools as capabilities passed at invocation.
• microVMs (e.g., lightweight virtualization) or hardened containers add a real boundary. gVisor or similar user-space kernels can reduce the syscall surface the agent can touch. On multi-tenant hosts, these boundaries matter.
• Syscall filtering (seccomp profiles), read-only root filesystems, minimal images, memory limits, and egress allowlists are boring controls that do more good than a new IDS every time.

Attestation is how you convince yourself and your partners that the code handling secrets is what it claims to be, running in an expected environment. Trusted execution environments (TEEs) support remote attestation: an enclave produces a signed statement tying a measurement (hash) of code and configuration to a hardware-backed identity. Cloud providers expose variants of this with different isolation properties. You can also layer in platform attestation via TPMs where available.

Attested agent runtimes do not need to process every request inside a TEE to get value. Consider:

• Use a TEE to hold keys and perform message-layer decryption and signature verification, then pass minimal plaintext onward to a sandboxed agent process via a narrow IPC channel. Secrets never leave the enclave.
• Keep a small verifier enclave that checks policy, rate limits, and tokens, then hands tokens to tools only after proof-of-possession is satisfied.
• Produce an attestation bundle alongside agent outputs. Downstream systems can choose to accept outputs only if they carry fresh attestation evidence tied to your expected code measurement and configuration.

Remote attestation adds friction. Measurements change with builds. Hardware capabilities vary across regions. Costs add up. Yet the posture it buys is worth it where agent context includes credentials, health data, or proprietary prompts. The math is clean: middleboxes can take memory snapshots, hosts can be forensically imaged, and contractors can be curious. An attested boundary restricts the blast radius. If you cannot or will not adopt TEEs, at least implement attestation-like checks at the software layer: signed container images, verified boot signals from the node, and a policy engine that refuses to run unmeasured code.

Tie identity to runtime properties. Use mTLS between agents and tools with SPIFFE-like identities that reflect both workload and environment. Bind tokens to the TLS channel (DPoP or mTLS-bound access tokens) so a leaked bearer token is less than a skeleton key. Scope tokens tightly with expiration minutes away, not days. Short-lived credentials with automated refresh are not just good hygiene; they turn a forensic log into a timestamp, not a breach.

Operations Built for Forensics

The hardest part of agent security is not a cipher choice. It is behavior under pressure. Someone will misconfigure a proxy. A vendor will admit an edge cache leaked memory. A developer will throw a prompt into a header for easy debugging and forget to remove it. You cannot eradicate these mistakes. You can build an operational stance that makes them survivable.

Start with logging discipline. Log what you need, at the right boundary, in the right place. Avoid body logging by default, especially at the edge. Prefer structured logs with explicit fields and mandatory redaction at the producer. Ship logs encrypted at the record level with keys controlled by your team, not just encrypted in transit to a third-party aggregator. If you must retain sensitive fields for debugging, keep them in a vault-like store with access mediated by a break-glass process, not in the stream everyone can query.

Don’t let secrets travel farther than they must. That means:

• No long-lived bearer tokens embedded in prompts or tool arguments. Use proof-of-possession tokens that are bound to a client key or channel, and rotate them frequently.
• Derive scoped credentials per tool invocation where possible. Macaroons and similar attenuated tokens are useful here: you can add caveats that restrict scope by method, resource, or expiration without minting new keys downstream.
• Keep the “secret zero” outside your agent where possible. Use a hardware-backed KMS to unwrap per-session keys. Do not check out the long-lived key into RAM of a general-purpose process if a small enclave or sidecar can do the unwrap and hand back a short-lived handle.

Build egress constraints that tell you when the agent steps outside its lane. A default-deny egress policy with explicit allowlists per agent tool is tedious at first and painless after a week. Pair it with DNS policies and TLS inspection only where you control both ends. If the payload is message-layer encrypted, your egress proxy can still observe destinations without learning content. That’s the balance you want.

Design for key rotation. Keys die. Have a runbook that rotates them automatically when you smell smoke. Derive per-session keys from a short-lived root; that way, you can rotate without stalling every live connection. Encrypt agent state at rest with keys that are easy to rotate without re-encrypting terabytes. If you need to re-key, do it in the background without breaking SLAs.

Adopt canaries and watermarks. Seed non-sensitive canary values in agent context that will trip alarms if seen in the wrong logs. Watermark outputs so that if a dataset trained on your agent’s private interactions shows up where it shouldn’t, you can prove lineage without public finger-pointing. These do not prevent leaks; they make them discoverable and demonstrable.

Assume subpoenas and audits. Keep a tamper-evident trail of configuration changes, key issuance, attestation verifications, and policy decisions. This is not theater. When an incident happens, you want to tell a coherent story about what the system promised, what it actually did, and why that promise held. In places like Dubai where large programs often coordinate across regulated entities and vendors, being able to show that intermediaries could not read agent content by design is sometimes the difference between an uncomfortable meeting and a delayed launch.

Finally, design your degradation modes. When attestation fails, do you refuse the request, or do you process it with reduced capabilities? When the egress proxy is down, do you buffer or drop? When an upstream tool demands an inspection header you will not send, do you stub the call or route to an alternate provider? Make these decisions now, not at 3 a.m.

A Stack You Can Ship Now

Here is a stack that meets the bar without exotic dependencies or philosophical purity. It will look familiar if you have built zero-trust internal systems. The twist is to use the same discipline for outward agent traffic that crosses untrusted proxies.

Protocol:

• Use TLS 1.3 over HTTP/2 or HTTP/3. Where available, enable ECH and DNS-over-HTTPS/QUIC for on-path privacy. Do not rely on them for content protection.
• Frame a message-layer envelope around all sensitive payloads. Use an AEAD scheme with nonces and per-message associated data that binds context (e.g., session ID, sequence number). Implement this over HTTP request/response and any streaming channels. Prefer a compact, binary serialization like CBOR or MessagePack to avoid incidental leaks via string serialization quirks.
• Establish keys via a modern KEM-based handshake (HPKE fits) or a standard asymmetric key exchange with ephemeral keys. Rotate keys per session and per tool. Bake in replay protection with sequence numbers and expirations.
• Keep HTTP headers minimal. Use Cache-Control: no-store where appropriate. Carry any routing state as an opaque token with a MAC, not as rich context.

Identity and authorization:

• Use mTLS between the agent and internal tools. For third-party tools, bind access tokens to the TLS channel where supported or to a client-held key (DPoP-like patterns). Keep tokens short-lived and scope them narrowly to methods and resources.
• When delegating, use attenuated credentials. Macaroons let you add caveats without minting fresh secrets downstream. They are a good fit for tool-specific capabilities.
• Authenticate peers at the application layer in addition to TLS. Message-level signatures help detect misrouting and downgrade attacks.

Runtime and attestation:

• Run the decryption and key management logic inside a TEE where the platform makes this straightforward. Keep the agent business logic in a tight sandbox with explicit capabilities. Connect them via a small, audited interface.
• If TEEs are not available, sign container images, verify on startup, and refuse to run if the measurement is unknown. Tie workload identity to that measurement.
• Enforce egress allowlists per tool. Block DNS by default. Make exceptions explicit.
• Use WebAssembly or hardened containers for the agent runtime. Keep the hostcalls minimal. No ambient filesystem, no shell.

Observability and operations:

• Log structure, not content, at the edge. Redact aggressively where content must be logged. Encrypt logs at the record level with keys under your control.
• Seed canaries, watermark high-value outputs, and monitor for exfiltration patterns.
• Automate key rotation and have explicit runbooks for suspected leaks. Keep secrets short-lived and bound to channels to reduce the blast radius of logs falling into the wrong hands.
• Define degradation policies. Fail closed on missing attestation if the data is sensitive. Route around unavailable WAF features if the payload is already protected at the message layer and risk is acceptable.

Agent orchestration security deserves its own note. Orchestrators are tempting centralizers of secrets and context. They also present a single throat for proxies to inspect if you are careless. Treat the orchestrator as a router of ciphertext. Each tool call gets its own envelope and its own key. The orchestrator holds no long-term secrets, only the minimum keying material to perform fan-out, ideally inside a TEE or with a sidecar that never exposes raw keys to the orchestrator process. Enforce tool invocation policies with a dedicated engine at the boundary, not in application code scattered across agents. When agents call each other, make them do so as peers with mTLS and explicit capability tokens, not as ambiently trusted voices inside the same process.

Now to the obvious counter-argument: isn’t TLS to a reputable CDN plus a good WAF enough? For static sites or simple APIs, maybe. For agents that blend private prompts, user data, and tool credentials, it is not. A CDN adds real value: DDoS absorption, routing, caching, and sometimes bot mitigation. You can keep those benefits and still treat the CDN as untrusted for content. The trade-offs are real: you lose body inspection at the edge and some caching opportunities. You gain the ability to say, with a straight face, that neither your CDN nor your observability vendor could read agent content even if they wanted to. In regulated environments, that matters. In adversarial environments, it matters more.

The performance hit is smaller than it sounds. AEAD on modern hardware is cheap. Message-layer encryption adds a handshaking step for key establishment and per-message overhead for nonces and tags. On well-tuned systems, the latency cost hides under the noise floor of a typical cross-region call. If your edge needs to rate-limit or route based on content, design the metadata you expose to enable that. Keep it narrow and non-sensitive. Push everything else behind the envelope.

None of this requires new standards to settle. It requires discipline. Pick a serialization and an encryption library you trust. Make message envelopes boring and repeatable. Bake replay protection and padding into your framing so teams do not reinvent it piecemeal. Put a small attestation verifier in front of high-value tools. Set up egress constraints. Then build agents that assume the pipe is not just monitored but curious.

Two more pragmatic points:

• Test for leaks by design, not by accident. Run synthetic traffic with markers through your stack and inspect what your proxies, caches, and log sinks observe. If they can reconstruct the flow, you have more to wrap.
• Coordinate with vendors. Tell your CDN you will carry opaque bodies and need only coarse controls at the edge. Ask your observability provider how to ship encrypted logs with customer-managed keys. If they cannot support that model, decide whether the convenience is worth the risk.

A regional footnote: many Gulf organizations run multi-entity programs where vendors, government-linked entities, and private operators share infrastructure and networks. Cross-border routing is common; content inspection is sometimes mandatory at specific points. Designing agent protocols as if intermediaries are untrusted is not rebellion. It is a way to bound what any party can see, avoid inconsistent handling across jurisdictions, and show auditors that sensitive agent context never left a small, measured surface.

The stack above is not utopian. It will not stop social engineering. It will not prevent a malicious tool from exfiltrating data once it sees it. What it does is draw a line between what a curious or compromised intermediary can do and what it cannot. It shifts the contest from “who happened to sit in the middle this week” to “who has a measured seat at the ends.” That is progress.

Designing agents this way has a side effect: it improves your development culture. When teams cannot casually read payloads at the edge to debug, they add the right hooks and tracing at the right boundary. When secrets are short-lived and bound to channels, they stop traveling in screenshots. When attestation is required, build pipelines get tidier because code identity becomes an operational dependency, not an afterthought.

We built our first waves of network safety on the promise that the pipe was secure. It was good enough when payloads were idempotent JSON and assets we could re-mint on a cache miss. Agents are different. They carry context that can be abused if seen, and they call tools that can cause real‑world effects if misused. Treating intermediaries as untrusted is not paranoia; it is how you match the stakes.

Stop assuming your proxies are on your side. Ship end-to-end encrypted agent protocols. Run agents you can attest, not just trust. Operate as if tomorrow’s incident report contains your request headers. If your agent cannot survive the front page of your own logs, it is not fit to run on the internet.