When Logging Becomes Leaking

Sensitive data hides in the URLs your systems quietly log everywhere, and those logs increasingly feed AI. Here is a per-session way to make a logged URL meaningless to anyone who was not meant to read it.

By Jose Lejin P J · Principal Engineer & Inventor · Cybersecurity • Applied AI / GenAI • Cloud Platform Engineering · 50+ U.S. patent filings

Your traffic is encrypted end to end, so you assume the sensitive value in that web request is safe. It travels over TLS, arrives at the server, and does its job. What you may not picture is the trail it leaves behind. That request was a GET call, the sensitive part rode in the URL, and along the way a copy of that URL was quietly written into the browser's history, the content delivery network's logs, the load balancer, the gateway, and a log pipeline or two after that. The data was protected in motion. It is now sitting, in the clear, in half a dozen places you do not directly control, waiting for the day one of those logs is exposed.

That quiet gap between "encrypted in transit" and "copied into logs everywhere" is the problem behind one of my granted patents, US 12,401,708 B2, "Systems and methods to protect against information disclosure," which I hold as the sole inventor. It is about the difference between protecting data while it moves and protecting it where it comes to rest.

The problem: logging is a leak we choose on purpose

Modern web applications and network management interfaces are built on REST, and REST leans on GET calls that carry information in the URL: identifiers, parameters, tokens, the specifics of a sensitive operation. That is by design, and so is the logging. URLs get recorded almost everywhere for entirely good reasons: debugging, analytics, performance, and security monitoring all depend on it.

The trouble is that a URL is not written once. As a request crosses the internet, it is copied into a long chain of logs: the user's browser history, the CDN at the edge, the perimeter load balancer, the gateway, reverse proxies, and the application's own logs, then often forwarded into a central log store. Encryption in transit protects none of these. TLS secures the wire between hops; it does nothing about the plaintext copy each hop writes down.

So you end up with a strange asymmetry. Enormous effort goes into protecting data as it moves, and almost none into protecting the many at-rest copies that logging leaves scattered across systems owned by different teams and vendors. Every one of those copies is a small, permanent exposure. The breach does not happen when the request is sent. It happens months later, when one of those log stores is misconfigured, over-shared, or stolen, and every sensitive URL it ever recorded is suddenly readable.

The idea: make the URL meaningless to everyone but the two ends that matter

The approach in the patent starts from a simple reframing. If URLs are going to be logged everywhere no matter what, then the URL that gets logged should carry no meaning to anyone except the client that sent it and the server that answers it.

It works per session, with a matched pair of components on the client and server.

When a session begins, the server generates a dynamically and randomly generated URL map that is unique to that session. The map is simply a set of positions in the URL and, for each position, a number of random characters to insert. The server keeps the map in session memory and sends a copy to the client, for example as part of the login response, where it lives only in the session's memory in the browser.

From then on, whenever the client makes a GET call to an endpoint the application owner has marked as sensitive, the client-side component injects random junk characters at the positions the map specifies. The URL that actually travels the network, and therefore the URL that lands in every log along the way, is scrambled into something unintelligible. Anyone reading those logs sees noise. The server, which generated the map and holds it for the session, simply reverses the transformation, recovers the original URL, and serves the request as normal.

A few properties make this more than a clever trick. The map is regenerated every session, so there is no static secret to steal, and a value that looked one way today is scrambled a completely different way tomorrow. The application owner chooses which endpoints need protection and how aggressive the scrambling is; enough of the URL is randomized that what remains in a log is not reconstructable. And it rides on standard session infrastructure, so it slots into existing web servers without a new secret-management system to run.

Why this matters for security

This closes a gap that most defenses simply do not cover.

• It protects data at rest in logs, not just data in motion. TLS guards the wire. This guards the dozens of plaintext copies logging leaves behind, which is where this class of leak actually happens.
• It shrinks the blast radius of a log breach. When a log store is exposed, and log stores are exposed all the time, the sensitive URLs inside it are already meaningless. A leaked log becomes a file full of junk.
• There is no long-lived secret to compromise. Because the map is per session and randomly generated, there is nothing durable for an attacker to exfiltrate and reuse. Yesterday's map decodes nothing today.
• It defends a surface nobody owns. The logging chain crosses browsers, CDNs, load balancers, and gateways run by different teams and vendors. Securing the URL at the source protects it across all of them, without needing to fix each one.

The elegance is that it does not ask you to log less. Logging stays exactly as useful as before. It just makes sure that what gets logged cannot hurt you.

Where AI changes the stakes

Here is why this matters more now than when logs were just logs. Logs have quietly become one of the most valuable and most consumed data sets in the modern stack, and increasingly the consumer is a machine.

Organizations now pour their logs into AI-powered observability, log-analytics copilots, and anomaly detection, and in many cases into datasets used to train or ground models. That means a sensitive value sitting in a logged URL is no longer just at risk from a future breach. It can be ingested, indexed, embedded, and surfaced by AI systems, potentially reappearing in a model's output to someone who should never have seen it. The log has become an input, and sensitive data in URLs is exactly the kind of thing that leaks in through that door quietly.

Protecting the URL at the source cuts that off cleanly. If what reaches the logs is junk, then everything downstream, every AI system that feeds on those logs, only ever sees junk. You do not have to trust every analytics tool, every model pipeline, and every retention policy to handle the sensitive value correctly, because the sensitive value was never there to begin with.

The pattern also runs the other way. As AI agents make more of the calls themselves, firing off GET requests across services at machine speed, they generate the same logged URLs a human would, only far more of them. A per-session scheme that renders those URLs meaningless in the logs keeps a fast, autonomous fleet from quietly seeding sensitive values across an observability stack that now doubles as an AI training ground. And the decision of which endpoints deserve protection, today set by the application owner, is a natural place for a model to help, learning to recognize the URLs that carry sensitive information and flag the ones left exposed.

The larger lesson

There is a principle worth carrying out of this. Encrypting data in motion is only half the job, because data has a second life in the logs, and that life is long, widely copied, and increasingly read by machines. We have trained ourselves to secure the moment of transmission and to treat everything that happens to a copy afterward as somebody else's problem. The logging chain is where that assumption quietly breaks.

The fix is to protect sensitive data where it comes to rest, not only where it moves, and to do it at the source, so protection travels with the data through every system that records it. Make the sensitive part meaningless to everyone except the two endpoints that genuinely need it, and an entire category of slow, delayed, log-based leaks simply stops being possible, whether the eventual reader is an attacker with a stolen log or an AI model trained on one.

Practical takeaways

• Treat logs as an exposure surface, not just an operational one. Every place a URL is logged is a place sensitive data can leak later. Inventory where your URLs actually land.
• Do not put sensitive data in the clear in URLs. If it must ride in a GET call, transform it at the source so what gets logged is meaningless without a key only the endpoints hold.
• Prefer per-session, regenerated secrets. A map or key that changes every session leaves nothing durable for an attacker to steal and replay.
• Protect at the source, not per hop. The logging chain crosses systems you do not own. Securing the value before it leaves the client covers all of them at once.
• Assume your logs will feed AI. Anything sensitive in a log can be ingested and surfaced by downstream models. The cleanest defense is to ensure the sensitive value was never readable in the log at all.

Closing

The most patient leaks are not dramatic. They are a sensitive value, riding in a URL, copied faithfully into a dozen logs by systems doing exactly what we asked them to do, and waiting quietly until one of those logs is exposed or fed to a model. Making that logged URL meaningless to everyone but the client and server that share a per-session map turns all of those copies into harmless noise. Logging stays as useful as ever. It just stops being a way to leak. And in a world where our logs have become the raw material for AI, the safest sensitive value in a log is the one that was never really there.

This article describes my own granted U.S. patent, US 12,401,708 B2, of which I am the sole inventor. The full record is publicly searchable through the USPTO and Google Patents.

Written by Jose Lejin P J. I spend my days building cybersecurity and applied-AI systems at internet scale, and I have spent the last several years turning the small frictions I run into along the way into 50+ U.S. patent filings. I write about cybersecurity, applied AI and GenAI, cloud-platform engineering, and the craft of innovation, the everyday business of turning friction into real inventions.