The AI Leak Isn't What Comes Back. It's What You Send.

Most of the worry about AI points in one direction: what if it gets something wrong? The hallucination, the confidently false answer, the bad output. Fair enough, that matters.

But the risk that actually keeps me up is the other direction. Not what the AI sends back, but what your people send it. Because every prompt is data leaving your building, going to a third party, often to be stored, and you cannot get it back.

The leak nobody logged

Here is how it happens, and it is completely innocent. Someone on your team is stuck. So they paste the thing they are stuck on into an AI tool: a customer email, a contract clause, a chunk of code, a spreadsheet of figures. The AI helps. It works brilliantly. So they do it again tomorrow, and the day after.

Nobody logged any of it. Nobody approved it. And the moment that prompt was sent, the data was gone. You cannot unsend it. Whatever was in it, a customer's personal details, an API key someone left in the code they pasted, a commercial figure that should never have left the building, is now sitting on someone else's servers.

It is not one big dramatic breach. It is a thousand small ones, distributed across your whole team, happening every day, invisible to everyone. And the people doing it are not being reckless. They are trying to do their jobs faster. The gap is not a motivation problem. It is a structural one: there was simply nothing standing between the paste and the send.

The few things that must never leave

Most of what flows through your AI is fine. You do not need to stop it, you need to be able to see it, which is a different job.

But there is always a narrow set of things that must never leave, full stop. Card numbers. A specific internal secret or credential. A particular client's personal data. For those, finding out after the fact is no use to anyone. By the time a human reviews the record, the data has already gone. You cannot review your way out of a leak that has already happened.

That is the line. For almost everything, watching is enough. For the genuine red lines, watching is too late. You need something that stops them before they leave.

What data-loss prevention actually is

The plain-English version is simple. It is a hard rule that catches specific data on the way out and stops it before it reaches the AI provider. The outbound request gets scanned, matched against your rules, patterns like card numbers, the shape of an API key, a named keyword, and if it trips one, it is blocked or stripped before it goes anywhere.

The enterprise world calls this data-loss prevention, or DLP, and usually buries it in a tier you have to phone someone to buy. Strip the acronym away and it is just this: some things you decide, in advance, are never allowed to leave, and you enforce that at the door rather than in the incident report.

Why this is a different tool from oversight

This is the part people get wrong, and it is the same distinction I keep coming back to. Oversight and prevention are two different jobs.

Oversight watches everything and blocks nothing. It records what happened so you can review it, and it never gets in the way of the work. That is the right default for almost everything, and it is why I keep human review non-blocking: the request goes through, the flag drops into a queue, nobody's AI breaks.

Prevention is the opposite, and it is deliberate. A hard block that refuses the request, reserved only for the narrow set of things that genuinely must never leave. You accept that it can say no, because for that category, no is the right answer.

The discipline is keeping them apart. Block everything you notice and you have built a tool that constantly breaks your own AI. Leave your red lines to after-the-fact review and you have built a tool that documents your leaks instead of stopping them. Flag and review the many. Hard-block the few.

You don't always have to block the whole thing

There is a gentler version that covers a lot of cases. You do not always need to refuse the entire request, you just need the sensitive part not to leave.

So you redact it. The email address becomes [email], the card number becomes [card], the secret is stripped out, and the rest of the prompt goes through as normal. The AI still helps with the actual task. The thing that should never have left never leaves. Most of the time that is all you want: the work gets done, minus the bit that was never safe to send.

The bottom line

You cannot recall a prompt. That is the whole thing in a sentence. Once data has left, no amount of logging, reviewing, or apologising brings it back.

So the only place to stop a leak is before it leaves. Oversight tells you what your AI is doing, and you need that. But for the handful of things that must never go out, you need a door, not a diary.

That is what SpendLil's Business tier does: hard-block data-loss rules for the genuine red lines, redaction for everything in between, sitting in front of every provider your team uses. Because the cheapest leak to deal with is the one that never happened.