Your Logs Are Leaking Secrets to AI A new analysis from Versus Control warns that logs routinely leak secrets such as bearer tokens and passwords, and that sending logs to AI models without redaction risks exposing sensitive data to third parties. The open-source Versus Incident agent includes a redaction layer that scrubs secrets before any downstream processing, storage, or AI model access, and the company advises making redaction the first step in any log pipeline. Why redaction belongs first in your log pipeline — and what a minimal one looks like. Most teams find out the same way. Someone on the security side runs an audit of the log aggregator, greps for Authorization:, and gets thousands of hits — real bearer tokens, in plaintext, searchable, retained for ninety days. Nobody put them there on purpose. A framework logged the request headers on an error. A retry logged the full URL, credentials, and all. A stack trace printed an object that happened to carry a password field. Logs leak secrets constantly, and it’s almost never malicious. It’s the default behavior of tools you already run. That was survivable, more or less, when your logs only ever went to a bucket you controlled. It stops being survivable the moment you point something external at them — a SaaS log product, a third-party APM, or the new one on everyone’s roadmap: an AI model that reads your logs to help with incidents. Now the secret doesn’t just sit in storage. It gets sent somewhere. Maybe embedded. Maybe retained by a vendor you never reviewed for this. This post is about the fix: a redaction layer that runs before your logs reach anything external, including an AI model. I’ll cover the patterns worth catching, why redaction has to be the first step rather than a later one, how to extend it for your own app, and how to check that it actually works. For the concrete parts I’ll use the redactor in the open-source Versus Incident https://github.com/VersusControl/versus-incident agent, mostly because I can show you the real patterns and config — but nothing here is specific to one tool. Before you can scrub secrets, it helps to know what shapes they take in a log line. Here are the ones that show up again and again, with the pattern that catches each. These are the built-in rules the agent ships with, and they’re a reasonable starting list for any pipeline: Two things stand out once you write the list down. First, most of these have a recognizable shape — that’s exactly why a regex layer works at all. Second, none of them got into your logs because an engineer decided to log a secret. They got there because something logged a header, a URL, or an object, and the secret was along for the ride. Here’s the mistake I see most often: teams treat redaction as an egress step. They scrub on the way out to the third party, right before the API call. It feels right, and it’s a trap. By the time a log line reaches the egress point, it has already been through your whole pipeline. It was parsed. It was probably grouped and stored. If you’re running any kind of log analysis, it may have been indexed or embedded. Scrubbing at the exit door means the secret still got written to disk, still got learned, still sits in five places you forgot about. You closed the front door and left the windows open. Redaction has to be the first thing that touches a log line, before anything else gets a copy: That’s how the agent wires it. The scrub happens the instant a signal is read, ahead of filtering, grouping, storage, and the model: The payoff is a single, checkable guarantee: a password redacted at this step never gets learned, never gets written to the pattern catalog on disk, and never leaves the box inside a prompt. Everything downstream only ever sees the scrubbed copy. When “does our AI ever see a real token?” comes up in a review, the answer is a position in a pipeline, not a hopeful “probably not.” If you’re wiring an LLM into your own log pipeline rather than using an existing tool, this is the one component I’d tell you not to skip and not to bolt on later. A redactor is small — a list of patterns, run in one place, before anything else touches the line — and it’s the difference between “we send logs to a model” being a shrug or an incident. Build it first, make everything read through it, and you never have to retrofit it under audit pressure. What the component actually has to do is short: That’s the whole shape. Here’s what a scrub looks like in practice; the labeled token is what lets you review the redactor’s work without seeing the thing it removed: before: user alice@corp.com logged in with token=sk live 9f2abafter: user