Sometime in the last year, someone on your team pasted something into a chatbot that they should not have.
Maybe it was a log excerpt with internal hostnames in it. Maybe it was a suspicious email, forwarded headers and all. Maybe it was a config file with a credential nobody noticed on line 40. It was almost certainly done with good intentions, under time pressure, by someone trying to move faster on real work.
This is not a story about careless analysts. It is a story about a question most teams never actually answered: what is allowed to go into these tools, what is not, and who decided?
Every prompt is a data transfer. The moment you treat it that way, most of the hard questions about AI in security work become ordinary data handling questions, and ordinary data handling questions have answers.
Most guidance in this space fails in one of two directions. Corporate policy documents say "do not share sensitive information with AI tools" and stop there, which is the same as saying nothing, because the entire question is what counts as sensitive and what to do when the sensitive thing is exactly what you need help with. Vendor marketing goes the other way and implies that an enterprise agreement makes the question disappear. It does not.
What follows is a rule set you can actually run a team on.
Every prompt is a data transfer
When an analyst pastes text into a hosted LLM, that text leaves your environment and lands in someone else's. From that point, the questions that matter are the same ones you would ask about any third party data flow:
- Where is it processed and stored, and for how long?
- Is it used for model training, and is that the default or an opt-out?
- Who at the vendor can access it, under what conditions?
- What happens to it if the vendor is breached, subpoenaed, or acquired?
- Can you delete it, and would you ever know if deletion failed?
None of these are exotic. Your team already asks them about SaaS log shipping, ticketing systems, and cloud storage. The only reason LLMs feel different is that the interface is a chat box, and chat boxes feel ephemeral. They are not. They are ingestion endpoints with a friendly UI.
Once you frame it that way, you can stop debating "is AI safe" in the abstract and start sorting actual data into actual categories.
A rule set you can run a team on
Three tiers. Green goes in. Yellow goes in after sanitizing. Red does not go in, full stop, and gets a different workflow instead.
Green: paste freely
- Public information: published advisories, CVE descriptions, vendor documentation, news coverage, open source code
- Questions phrased generically: "how does EtherNet/IP authentication work" instead of "here is our PLC config, what is wrong with it"
- Text you wrote from scratch for the purpose: a draft blog post, a generic detection idea, a request to explain a technique
- Code that contains no secrets, no internal naming, and nothing proprietary
A useful test: if you would be comfortable posting it to a public forum under the company name, it is green. That bar sounds extreme until you remember that you have no enforceable control over where a prompt ends up. The bar is the bar.
Yellow: sanitize first, then paste
- Log excerpts, after stripping hostnames, internal IPs, usernames, account identifiers, and anything that maps to a real system
- Phishing emails, after removing recipient addresses, internal routing headers, and tracking tokens
- Error messages and stack traces, after checking for embedded paths, keys, and connection strings
- Internal documentation, rewritten as a generic description rather than pasted verbatim
The honest rule for yellow: paraphrase beats redaction. Redacting a document line by line under time pressure fails in predictable ways, because the sensitive part is often structural, not a string you can black out. Describing the situation in your own words, with placeholder names, is slower for the first sentence and safer for all of them.
Red: does not go in
- Credentials, tokens, keys, and certificates, including expired ones, because expired credentials still reveal naming conventions, formats, and infrastructure
- Active incident data while the investigation is open. Mid-incident, you do not yet know what the data is. The log excerpt that looks routine on Tuesday is evidence by Friday
- Unpatched vulnerability details about your own environment
- Customer data, employee PII, and anything under regulatory scope or legal hold
- Proprietary detection logic, because your detection rules describe your blind spots as precisely as they describe your coverage
Red does not mean "AI cannot help with this work." It means the hosted chat box is the wrong tool for it, and the workflow needs to change rather than the rule.
"We have an enterprise agreement" is not the whole answer
Enterprise tiers genuinely matter. Contractual no-training commitments, shorter retention windows, and SSO-gated access are real improvements over a consumer account someone signed up for with a personal email. If your team uses hosted AI tools, it should be under an enterprise agreement, and verifying the no-training and retention terms should be part of procurement.
But an agreement changes the terms of the data transfer. It does not make the transfer stop being one.
The vendor can still be breached, and prompt history is a high-value target precisely because of what people paste into it. Retained prompts can still be discoverable in litigation. A browser extension or "AI-enhanced" integration someone installed can still route data to a different service than the one you reviewed. And the agreement does nothing about the analyst who, finding the approved tool slower than the consumer one, quietly uses the consumer one.
The agreement is a control. It is not a category change. Red stays red.
When the answer is no, bring the model to the data
Here is where most policies stop and most teams get stuck. The data that is most useful to analyze with an LLM, the messy logs, the incident timelines, the internal reports, is exactly the data that should not leave the building. If the policy ends at "no," analysts route around it, because the work still has to get done.
The way out is to invert the flow. Instead of sending data to the model, run the model where the data already lives.
This is the practical case for local LLMs in security work, and it is a stronger case than the hobbyist framing suggests. A local model running on an analyst workstation or an internal server can summarize an incident timeline, structure messy notes into a report, draft a first-pass analysis of a log excerpt, or turn a pile of observations into a clean handoff, all without a single byte of red-tier data leaving your environment. The model is smaller and less polished than the frontier hosted ones. For this class of task, it does not need to be frontier. It needs to be good enough, and private.
The same human-in-the-loop rules apply that apply everywhere else: local models hallucinate too, and nothing about running on your own hardware makes the output trustworthy. What changes is the data handling question. It disappears.
If you want to go this direction, start with why local AI is worth taking seriously, then the hands-on guide to installing Ollama and putting it to work. A working local setup takes an afternoon, and it converts an entire category of "no" into "yes, locally."
Make it a rule, not a vibe
Right now, in most security teams, the paste decision is made individually, silently, dozens of times a day, by whoever happens to be holding the data. That is not a policy. That is a coin flip with extra steps.
Fixing it takes one page, not a governance program:
- Write the three tiers down, with examples from your own environment, and put them where analysts actually look
- Name the approved tools for green and yellow work, so nobody has to guess which chat box is sanctioned
- State the red list explicitly, including the mid-incident rule, because "use good judgment" is how good people make bad transfers at 2 a.m.
- Stand up the local option for red-tier work, so the policy offers a path instead of just a wall
- Revisit quarterly. Tools change, terms change, and a rule set nobody maintains becomes a rule set nobody follows
The teams that get value out of AI in security work are not the ones with the most permissive rules or the most restrictive ones. They are the ones where every analyst can answer, without hesitating, the question this post started with: can I paste this?
If they can answer it in under five seconds, you have a policy. If they have to think about it, you have a vibe, and vibes do not survive incident pressure.
Where to go from here
The rule set is the easy half. The harder half is standing up the local option so red-tier work has somewhere to go, and that is mostly a setup problem: the right model runner, a few supporting tools, and an afternoon you would rather not spend debugging install errors.
That is exactly what the free Cyber Pro's AI Toolkit is being built to solve: a clean install path for Ollama and nine supporting tools across macOS, Windows, and Linux, with verification steps so you know each piece actually works before you build on it. If you want it when it ships, along with the next analysis like this one, the briefing signup is at the bottom of this page.