Friends Don't Let Friends Use Public AI for OSINT

TL;DR

• A source can now target the AI reading it instead of the analyst, hiding instructions in places a person would never look and steering what makes it into the final summary

• Manual detection works, but someone has to run it on every file, every day, and most teams don't have time for that

• To use AI safely, it needs to separate evidence from instructions on its own, before a person has to catch it

In June 2026, researchers found malware built with something unusual inside it: 38 fake error messages, designed to make an AI-assisted analyst tool doubt itself and stop the investigation. The malware wasn't just trying to avoid detection. It was trying to talk the analyst's AI into giving up.

That's the direction this is heading in OSINT too, just aimed at a different outcome. Instead of getting the AI to quit, a source wants the AI to keep going and just leave a few things out.

Here's what that looks like in practice.

An analyst is working a case. She sets an AI tool loose on it: pull whatever's out there on a name, an address, a few aliases. It comes back with forum posts, screenshots, a couple of PDFs, a spreadsheet someone put together with names and links. Then it hands her key actors, a timeline, and a short list of things flagged for follow-up.

What she doesn't get back is the one post that would have blown a hole in the whole story. It wasn't hard to find. It wasn't buried in some obscure corner of the internet. Somewhere in that pile of material, something told the AI to leave it out.

The model didn't get anything wrong. A source reached past the analyst and gave instructions to the tool doing her research, and she has no way of knowing that from what came back.

This is called prompt injection, and it's becoming one of the harder problems in this line of work. More of the job now runs through a step most analysts aren't checking.

A new kind of source risk

OSINT has always run on one rule: question the source. Who made it, why it exists, what it wants you to believe. That hasn't changed. What's changed is who the source is talking to.

A source used to have one audience: the analyst reading it. Now it has two. It can still try to convince the person directly, the way it always has. It can also talk to the AI reading it for that person, without the analyst noticing.

A clean, confident summary can be more dangerous than a messy one. Three names, a tidy timeline, a confidence score, and nothing in the output shows whether the source had any say in what got included.

How prompt injection works

The instructions don't sit anywhere a person would normally look. They're built to be read by machines and skipped by everyone else.

A hidden label meant for accessibility readers, white text on a white PDF page, a spreadsheet cell formatted to disappear (sitting far outside the visible table). None of it shows up when you open the file normally, but all of it can get pulled in by whatever's reading the file for you.

Earlier this year, instructions aimed at AI coding agents turned up embedded in AWS documentation. The page looked normal to anyone reading it in a browser, but it told agents to run command-line tools nobody had asked for. The page showed the machine something different than what a person could see.

Nico Dekens, who writes as Dutch OSINT Guy, built a manual way to catch this:

• Preserve the source

• Compare what a person sees against what a machine actually extracts from it

• Ask the AI to flag anything that looks like it's trying to direct or suppress, instead of asking it to summarize outright

He turned this into a 20-minute check analysts can run before trusting a source with anything that matters

Why manual checking isn't sustainable

That check works when someone runs it. It catches things a normal read-through wouldn't.

But there's a harder problem underneath it. Researchers have documented sites that can tell when a visitor is an AI agent instead of a person, and serve it a completely different page. It's called AI-targeted cloaking, and it means the AI can come back with a clean answer built from content a person reviewing the same page would never see.

Even without that problem, a 20-minute check per file means checking every file, every day, and most caseloads don't leave room for that, especially once a case starts moving fast. Even if you do have time to check the files, none of what you found carries forward. One analyst catching a hidden instruction today doesn't protect the next person who opens that same file a month from now.

What it takes to use AI for OSINT safely

The manual discipline Dekens lays out is worth keeping. It just isn't something a team can rely on for every case, forever. To use AI safely, it needs to separate evidence from instructions on its own.

That gets enforced through skills, tool governance, agent instructions, guardrails, and asynchronous validation, not left to whatever an analyst types into a prompt that day.

• Mismatches between what's visible and what's machine-readable get flagged during processing

• Every claim carries a source locator by default, backed by lineage that traces each piece of output back to where it came from

• Nothing acts on an untrusted source without a person approving it first

• There's a record of what the model was given and what it handed back, so a strange result can actually get investigated

And sensitive material shouldn't have to touch a public AI tool at all. Private VPC, GovCloud, on-prem, air-gapped, and zero-retention deployment options exist for this reason.

Closing

Friends don't let friends use public AI for OSINT, and this is why. A public AI tool has no idea what it's reading, where it came from, or whether it should be trusted, let alone keep case data secure.

Right now, the responsibility to catch an adversarial source sits entirely with the analyst. It should sit with the system too.

—> See how Workstation handles source material before it ever reaches an analyst. Request a demo