Your CDN can read your secrets

Lately there's been a focus on how to use agents safely. This new security requirement comes from the possibility that an AI agent's uncertain behavior leads to leaked keys.

The placeholder proxy

One approach gaining traction is a man-in-the-middle (MITM) proxy that has access to all the secrets. The agents get PLACEHOLDER secrets, and the proxy swaps them for the real ones.

That sounds good and secure for most use cases. But it shifts the work to the proxy. It increases overall complexity and the proxy's scaling requirements, and now securing the proxy's own access and credential management needs more focus.

The assumption behind HTTPS

Another thing that's happened in recent years is our dependence on HTTPS, with the goal of preventing MITM attacks. The server can be verified through trusted root certificates, and traffic is encrypted end to end.

The implicit assumption is that TLS always terminates at a layer the server controls, usually a load balancer. Protocols like OAuth 2.0 rely on that assumption as the basis of their security flows.

Where it breaks: CDNs

Interestingly, this breaks when CDNs are used. CDNs can inspect the data and modify headers, so every secret key in a header is available to the CDN to read and change.

In practice, organizations are placing their utmost trust in how CDNs operate and how they store traffic logs. CDNs are treated as a proxy that will always follow the best security practices, above and beyond profit incentives. In some ways they're treated like a fiduciary: a person or organization legally and ethically obligated to act in another party's best interest.

It's like handing your house keys to a security company in exchange for some extra benefits.

It becomes a circular challenge when agents are used to manage code and infrastructure at these CDNs. Which way are you going to stop the accidental leak of credentials?

So where was I going with this?

1. Use the Authorization header. Assuming people value conventions, it's always safer to pass a security key in the Authorization header than in custom, arbitrary headers. Those may not be treated the same way by CDNs, and might be logged for analytics or ML.

2. Sign instead of sending the secret. AWS is probably one of the companies with some of the best security here. It never sends the secret in the request. Instead, it signs the content with the secret, which makes it relatively harder for bad CDN code to abuse.