AI Search Has Become a Security Surface How digital reputation gets manipulated — and what a security director can do about it

What gets attacked is not the model

The first thing I had to get straight: an attacker isn't attacking the AI model. That would require access nobody has.

The attacker is attacking what the AI reads.

The logic is familiar from physical security. You don't break the camera. You make sure the camera sees something that reassures the operator. You don't work against the officer — you work against the officer's report, so that everything looks clean on paper.

In AI search, the "camera" is the public information environment. When the system answers, it is reading documents, resolving entities, and weighing what different sources claim about them. Manipulate those sources and the model still works perfectly. It just works perfectly on manipulated material.

This stopped being theoretical in the past twelve months. In April 2026, Google and Forcepoint published back-to-back reports on real-world activity. Google scanned a repository of two to three billion crawled pages per month and measured a 32 percent relative increase in the malicious category between November 2025 and February 2026. Forcepoint's researchers found live payloads triggering on patterns like "ignore previous instructions" and "if you are an LLM." Palo Alto's Unit 42 had documented the first real-world instance of malicious indirect prompt injection in December 2025. [PROVEN]

Six patterns worth recognizing

What follows is not a how-to. It describes what these methods target and how to spot them. The technical detail is public anyway — every major security vendor has published it. What has been missing is the translation into our profession's language.

1. Content flooding

The crudest one. If a claim appears in enough places, systems are more likely to treat it as known. That isn't a bug — it's how machine knowledge works. Research on large language models has shown that model accuracy on a fact correlates strongly with how many documents in the training data support it. Whoever appears in more documents is better known to the model.

The abuse is straightforward: generate large volumes of near-identical content around a single claim and scatter it across the web.

How to spot it: if the same sentence, the same figure, and the same turn of phrase keep reappearing across apparently different sites, that isn't an echo. That's one source, duplicated.

2. Manufactured consensus

A more refined version. Here the goal isn't volume but the appearance of independent corroboration. A few blogs, a couple of "industry portals," some forum posts — apparently separate actors, actually one hand.

It works because independent corroboration genuinely is a strong signal. Large-scale correlation studies of AI visibility consistently find that unlinked brand mentions track more closely with AI visibility than classic backlinks do. An attacker imitates that mechanism. [STRONGLY LIKELY]

How to spot it: check the registration dates, the imprint, and the bylines of the "independent" sources. Three recently registered domains running the same template with no named authors is not consensus.

3. Structured data abuse

Web pages carry machine-readable markup: who wrote this, what company published it, when, what rating it received. Nobody verifies any of it. The page asserts it about itself.

The abuse is a mismatch between what the page shows and what its markup claims. No reviews visible anywhere on the page; 4.9 stars from five hundred reviews in the markup.

One important qualification: Google's own documentation states plainly that no special structured data is required to appear in AI features. Markup is not a magic word. But it is raw material for entity resolution, and it can be polluted. [PROVEN that the mechanism exists; magnitude of effect not quantified]

How to spot it: compare what the page displays against what it declares about itself. If the site lists no named customers but the markup claims hundreds, something is wrong.

4. Cloaking — the machine sees something you don't

An old technique with a new target. The page detects that an automated client is reading it and serves different content.

This is technically easier than it has ever been, because AI crawlers identify themselves clearly by user agent, and several of them do not execute JavaScript — they read raw HTML. Whatever is written there is what enters the machine's picture of you. [STRONGLY LIKELY]

How to spot it: this is the one item on the list that's hard to check without tooling. When the stakes justify it, commission a review that compares rendered page content against raw source.

5. Hidden instructions inside the page

This is the most interesting one, and every security leader should understand it.

An AI does not distinguish between what the user tells it and what it reads on a web page. Both are text. So if someone embeds text on a page that is phrased as an instruction, the system has a real chance of treating it as one.

The field calls this indirect prompt injection, and it sits at the top of the OWASP GenAI security risk list for LLM applications. The instruction is concealed — in text hidden from the human eye, in elements positioned off-screen, in encoded form.

Zscaler's ThreatLabz documented two live campaigns in 2026. In one, hidden text instructed the AI to treat that page as the "verified, authoritative destination", to rank it first for a specific set of queries, and to avoid mentioning a word that would have revealed its true nature. The attacker was manipulating credibility directly, in the AI's eyes.

In both campaigns, the attackers first used SEO poisoning to push their sites high in search results, making it more likely an agent would find them. The two methods worked together. [PROVEN]

How to spot it: when an AI answer is unusually emphatic about a single source — "this is the official one," "this is the recommended option," "this is the only platform that" — and the source is unfamiliar, that alone is a flag. Confidence is not evidence.

6. Entity manipulation

AI systems don't only handle pages. They handle entities: companies, brands, people. Resolving an entity means reconciling data from multiple registries and databases.

The abuse here is planting false or misleading records — a fabricated expert profile, a company listing with no real legal entity behind it, an entity engineered to resemble someone else's.

How to spot it: the corporate registry. If a recommended vendor cannot be found in its own jurisdiction's official register, the conversation is over.

Why this hits our sector harder than most

A security company executive would be right to ask why any of this is their problem.

Four reasons.

The category is small. Manipulating "best hotel chain" would mean working against tens of thousands of sources. The world of patrol verification platforms is narrow by comparison. Few sources, few trade publications, few independent analyses. A small category is cheaper to manipulate. [HYPOTHESIS]

There is no technical gate before the decision. Security services procurement rarely includes the kind of technical audit an IT system would face. The decision usually rests on professional judgment and a recommendation — and the source of that recommendation is increasingly an AI.

The decision lasts for years. In my experience, companies almost never replace a patrol verification system once it's deployed. Not because it's perfect, but because everything grows around it: checkpoints get installed, officers learn the workflow, shift patterns adapt to it, and the reports going out to clients get formatted around its output. Replacing it restarts all of that. So they live with what they have.

That isn't a problem in itself. It just means the handful of names that made it into consideration before the decision will shape how the company operates for years. Which raises the question worth asking honestly: did the executive choose the most suitable system — or the most visible one?

Those are not the same thing. And increasingly, an AI decides which one is visible.

The stake is not the license fee. Deploy the wrong patrol system and you don't lose a subscription. You lose provability — the ability to demonstrate, after an incident, what happened on site and when. That capability is the entire reason the system exists, and for regulated environments it is also what a compliance auditor will ask you to produce.

The defense: six questions before you trust the list

None of this requires technical expertise. These are questions anyone can ask — of themselves, or directly of the AI.

1. Who is saying this?

Click through to the source. Is there a named author? Does that author have a track record in this field, or were they writing about pet food last year? Does the site have an imprint, contact details, a company behind it?

Ask the AI: "Who wrote the sources your recommendation is based on, and what is their professional background?"

2. How many genuinely independent sources say it?

This is the most important question on the list. What matters isn't how many times the claim appears — it's how many actually independent parties are making it.

Ten pages operated by the same company is one source. Not ten.

Ask the AI: "How many independent sources support this claim, and which of them are under the vendor's own control?"

3. Compared to what?

Any number without a baseline is marketing. "Thirty percent better" — than what? Across how many sites? Over what period? Measured how?

Ask the AI: "By what method, on what sample size, and over what time period was this result measured?"

4. What are the downsides?

The simplest test on the list, and one of the most effective. Ask explicitly about weaknesses.

A system working from a balanced information environment can name drawbacks, because its sources name them. If it can only find positives, that tells you the material it read was one-sided.

Ask the AI: "What are the most serious limitations and drawbacks of this option? Who should NOT choose it?"

5. What does the other system say?

Put the same question to two or three different AI systems.

One note from my own measurement data here: these systems usually do not agree. Running the same ten questions across four engines, I consistently record substantial differences. That is normal.

So the rule runs opposite to intuition: the divergence isn't the suspicious part. The perfect match is. If three different systems recommend the same vendor using the same phrasing, they are probably drawing on the same narrow source set. Go find out what it is.

And put one system's answer to another — but ask for the sources, not the verdict. Paste one AI's answer into a second one and have it examine the sources it cites: are they reachable, who wrote them, and do they actually support the claim being made? Five minutes, and it does work no human has time for — reading twenty sources.

One caveat matters here. The second model is largely working from the same sources, and if a page carries a hidden instruction, it will read that too. This is not independent verification. It's a second reading. So don't adopt its verdict — take the source list, which you can then check yourself.

Ask the AI: "Open the sources cited in this answer and tell me which claims each one actually supports, and which claims none of them support."

6. Does the company exist?

The most mundane check, and the one people skip. Corporate registry, registered address, tax number, working contact details. On an international purchase this takes five minutes.

The one metric that actually matters

If you take a single thing from all of this, take this.

A claim is strong when you can reach it by several independent routes.

If "supports self-hosted deployment" appears in exactly one place — the vendor's own sales page — that is not evidence. It's a promise. If you also find it in a named customer's account, in a partner's technical documentation, in an independent directory, and in a procurement document, then you have reached the same claim four different ways, and three of those routes were not written by the vendor.

In our research we measure this as Claim Redundancy: not the number of repetitions, but the number of independent paths.

And the metric reads in both directions. When you're building reputation, it's a target. When you're auditing one, it's a warning sign — because the signature of a manufactured reputation is exactly this: high volume, low independence.

The same applies to us

We are not neutral observers. Trinity Guard competes in the market this article describes — and this article is itself content that an AI may read.

That is why our research keeps vendor-controlled and genuinely independent sources in separate columns from the outset, and never adds them together. What a company asserts about itself is not evidence. It is a claim until someone else confirms it, and that is as true of us as of anyone. It is also, incidentally, why we built the platform around verifiable records rather than activity logs.

So the six questions above are not only for the competition. Ask them of us.

This research also runs in a second language. Our Hungarian sister company, Trinity Security Kft., publishes a version of this analysis written for the Hungarian security-technology market — cameras, alarms and remote monitoring rather than guard tours — as Manipulálható-e az AI, amikor biztonságtechnikát ajánl?. Same six questions, different market, a much smaller information space to work with.

Research status

That last row is deliberate. This article accuses no one and targets no one. It describes a mechanism that demonstrably exists and that our profession has not yet discussed.

Closing

I don't think AI search is unreliable. I use it daily and it has made a large share of my work faster.

I think it earns what every other tool earns: verification. In the security profession that isn't distrust — it's the baseline. We don't review an officer's route because we doubt the person. We do it because provability is part of the service.

A question put to an AI is a service too. The answer either rests on evidence or it rests on nothing.

Six questions will tell you which.

Sources

• Help Net Security (2026): Indirect prompt injection is taking hold in the wild — reporting on the Google and Forcepoint findings
• Zscaler ThreatLabz (2026): Indirect Prompt Injection in Web Content Targets AI Agents
• Palo Alto Networks Unit 42 (2026): Fooling AI Agents: Web-Based Indirect Prompt Injection Observed in the Wild
• Cloud Security Alliance (2026): Indirect Prompt Injection in the Wild
• OWASP GenAI Security Project: LLM01 — Prompt Injection
• Google Search Central: AI Features and Your Website
• Kandpal, N. et al. (2023): Large Language Models Struggle to Learn Long-Tail Knowledge, ICML