Security Data and AI Tools: What Must Never Leave Your Estate

The paste that starts it

An analyst has a log format they do not recognize. Twelve lines, a vendor they have not worked with, and forty minutes of documentation ahead of them. They copy the lines into an assistant and ask what they are looking at.

Thirty seconds later they have a readable explanation and they carry on with the investigation.

This is the single most common way security data leaves an organization, and it is done by careful people with good intentions. Nobody is being reckless. The analyst has a problem, there is a tool that solves it, and the question of what was in those twelve lines never quite surfaces because the lines were the problem rather than the subject.

The purpose of this sub is to make that question surface automatically, and to make the answer cheap to act on. Not through a policy nobody reads, but through a habit that costs nothing at the moment it matters.

What is actually in a log line

Take a single row from the Northgate estate and read it as an outsider would.

2026-03-02T22:55:12Z  r.scott@ne.com  45.83.64.117  SRV-NGE-MCR-APP01
Office 365 Exchange Online  ResultType=0  singleFactorAuthentication

An analyst sees one successful sign-in. Somebody outside your organization sees:

• A real person's work identity, in a format that reveals the naming convention for every other employee
• Your internal hostname convention, which encodes the site, the function and the number, so SRV-NGE-MCR-APP01 tells a reader there is an APP02 and probably a DB01 at the same site
• Which services you run and which authentication method that service accepted
• The fact that this account authenticated with a single factor, which is a live weakness rather than a historical fact

One line. Now consider that the paste is rarely one line, and that a plausible request is "here are the last two hundred events, what am I looking at".

Four categories, and where the line falls

Not everything is equally sensitive, and a rule that treats it all the same is a rule that gets ignored on a busy shift. Four categories, in rising order.

1. Generic technical content. Query syntax, a public vendor field name, a CVE identifier, a general question about how a protocol behaves. Nothing here identifies your organization. "How do I express a time window in KQL" discloses that you use KQL, and that is all.

2. Structure without identity. A log format with the values removed, a schema, a rule template. This is where most genuinely useful requests live, and it is almost always safe. "Here is the shape of this log format with the values redacted, which field is likely to hold the source address" gets you the same answer as pasting the real lines.

3. Estate identifiers. Usernames, hostnames, internal addresses, application names, group names, file paths containing user directories. This is the category the opening example falls into, and it is the one people misjudge, because individually each item feels trivial.

4. The incident itself. What was compromised, when, what the attacker did, what you have and have not contained. This is the category where disclosure is not merely a privacy question but an operational one: the details of a live incident are the details an attacker would most like to know you know.

The questions that decide it

Three questions, in order, answerable in about ten seconds.

Does this identify us? Not "is it secret" but "could a reader work out which organization this is and how it is built". Hostnames and internal addresses answer yes almost always.

Would this help someone attacking us? A naming convention helps. A list of applications helps. Knowing which account authenticates without MFA helps a great deal.

Can I get the same answer without it? Nearly always yes, and this is the question that resolves the majority of cases. The analyst in the opening example did not need the values. They needed to know what the format was. A single line with the values replaced by placeholders gets an identical answer.

Making the safe path the fast path

Rules that depend on judgment under pressure fail under pressure, which is when they matter. Four things work because they do not require anyone to resist a shortcut.

Have an approved tool. The single largest driver of data going somewhere it should not is the absence of an approved place for it to go. An analyst with a sanctioned assistant that meets the organization's data terms does not paste into a consumer service; an analyst with nothing sanctioned finds their own.

Answer the question before it is asked. "May I use this for log analysis" needs a documented answer that an analyst can find in under a minute at two in the morning. An unanswered question resolves itself in favor of the shortcut.

Default to structure. Build the habit of asking about the shape rather than the content, because it is faster to redact by reflex than to assess each case. The reflex also survives fatigue, which the assessment does not.

Assume permanence. Whether a given service retains prompts, trains on them, or logs them for abuse monitoring is a question with a different answer per vendor, per tier and per year. The stable working assumption is that anything sent may persist somewhere you cannot reach, and that assumption costs you nothing if it turns out to be pessimistic.

The redaction that keeps the answer intact

The objection to redaction is that it might remove the thing the assistant needed. It usually does not, and it is worth understanding why, because that understanding is what makes the habit stick.

A model reading an unfamiliar log line is doing pattern work: this token is positional, that one is a timestamp, the third looks like an identifier, the structure suggests a particular vendor's format. Almost none of that depends on the values. Replace r.scott@ne.com with USER1 throughout and the structural answer is identical, because the question was about the shape.

Where values do matter, they are usually the ones that are safe to keep. A result code, a protocol name, an event ID, an error string: these are vendor vocabulary rather than estate detail, and they are precisely the tokens the assistant needs.

What a good sanctioned tool actually needs

If your organization is choosing what to approve, the questions that matter operationally are narrower than a procurement questionnaire suggests.

Does it train on your inputs by default, and can that be turned off in writing? The distinction between a consumer tier and a business tier is usually exactly this, and it is usually the whole of the difference that matters.

What is retained, for how long, and who can read it? Abuse monitoring is legitimate and it means a human at the vendor can potentially read a prompt. That is acceptable for category 1 and 2 content and is a genuine consideration for category 4.

Where does it run? Data residency is a real constraint for some organizations and irrelevant for others, and it is worth establishing which you are before the conversation rather than during it.

Can you demonstrate the terms to an auditor? Not whether you believe the terms are adequate, but whether you can produce them. The question is asked after an incident and it is asked in writing.

Notice what is not on that list: model quality. Whether the assistant is good at security work matters enormously for whether people use it, and not at all for whether it is safe to send data to. Those are separate decisions and conflating them is how organizations end up with a tool that is safe and useless, which analysts then route around.

If it has already happened

It has. Not necessarily to you, and if you manage a team, to somebody on it. Treat that as the starting condition rather than the failure state.

The useful response is not disciplinary. It is to establish what category was disclosed, because that determines whether anything needs doing at all. Category 1 or 2 needs nothing. Category 3 is worth recording, because a naming convention disclosed once is disclosed permanently and it belongs in your threat model rather than in a disciplinary file. Category 4, during a live incident, is a decision for whoever is running the incident and probably for legal.

The failure mode to avoid is silence. An analyst who believes disclosure ends their career does not report it, which converts a small, containable event into an unknown one. Whatever the policy says, the operational goal is that people tell you, and that goal is set by how the first report is handled rather than by what is written down.

Module 7 develops this into a working policy: what to sanction, how to write terms that survive a vendor change, and how to build a workflow where the compliant route is genuinely the quickest one available.