Featured

The Absence of Evidence Is Not Evidence of Absence

Cybersecurity Hits: 1769 36 minutes read

When an Assistant Reads What Another Assistant Wrote

Two sentences sum up the article. The absence of evidence is not evidence of absence. The presence of a demonstration is not evidence of prevalence.The Absence of Evidence Is Not Evidence of Absence - This is the third article in a series of four called "Without Noise Everything Is Clear" or "The Compressed Internet"

An early alert, together with everything that is not yet known.

This is the third article in a series of four called "Without Noise Everything Is Clear" or "The Compressed Internet", written with an advanced assistant in line with the editorial policy.

A confession before the beginning

In the first article of the series I said that I do not tell the stories of my clients' incidents, because they belong to the clients. That remains true. But I can say what I learned from them, without names and without details, and it bears directly on this text: in almost every security incident I have worked on, the hardest part was not what was seen. It was what was not seen.

An incident rarely comes with a map. It comes with a trace or two, and with a gap between them. The first reflex is to treat the gap as proof of absence: if it is not in the log, it did not happen. The second reflex, more mature and more uncomfortable, is to ask what exactly should have appeared in the log if the thing had happened, and whether the system would even have been capable of writing it there. Often, the answer to the second question changes everything.

I tell this because the subject of this article has exactly the shape of a gap. I say up front what I want to claim and what I do not. I want to claim that a certain mechanism is plausible and partially documented: one automated system can influence another automated system through the content that the first produces or serves and that the second reads. I do not want to claim that this mechanism is widespread, nor that it is growing, nor that it is currently producing, in the real world, a measurable harm. For none of these do I have evidence, and for some I do not believe the instruments to obtain it yet exist.

This is therefore an early alert, not a finding. The difference is one of legal type and of character: an alert says "something could happen here, take a look", not "something happened here, behold the damage". In a field where almost any unqualified claim quickly turns into a headline, I believe it is the only honest way to write.

One more confession, smaller. When I started this series, I expected this article, its original core, to be the easiest to write, because the idea seemed obvious to me: if assistants write more and more, and other assistants read more and more, the loop closes. As I read, the idea proved less obvious, not less plausible. I realised that "the loop" is in fact three different things, with three different levels of evidence, which I had mixed up in my head. Sorting them out is this text's most useful contribution, and that is why I give it space.

An alert, not a finding

Here are the three things, in a short table, with each one's evidence label. The rest of the article unfolds them one by one.

What is claimed

What exists

What is still rare

What has no data

A site can show the assistant something other than what it shows the human (cloaking)

Laboratory demonstrations (SPLX); the mechanism is technically documented

A commercial test on ~46 domains found differences on ~4%

The real prevalence across the web

Content can be written to influence an assistant, including its memory

50 cases across 31 firms in 60 days (Microsoft, observed in e-mail traffic)

The effect varied between platforms; some cases could no longer be reproduced

How many cases exist outside the observed e-mails; what effect they had on people

One assistant writes, another reads, and the loop closes

A non-negligible part of the web is written with AI assistance (Graphite, Pew); methods for optimising content for generative engines have been published (preprints)

Sources cited by assistants still appear predominantly human (Graphite)

Any measurement of the loop as such

Read the table by columns, not by rows. The "what exists" column is fuller than you would think if you had only heard the press headlines, and emptier than you would think if you had only heard some people's enthusiasm. The "what has no data" column is the longest, and not out of carelessness: that is what a phenomenon looks like at the beginning.

I continue to use four labels for the level of evidence, the same as in the rest of the series: [DOCUMENTED] for what has been observed and described by a source I can cite; [EXPERIMENTAL] for what has been demonstrated in a controlled setup; [ISOLATED] for what has been observed at a particular place and time without any claim of generality; [HYPOTHESIS] for what I or someone else asserts without a measurement.

The reader without a critical sense

[EXPERIMENTAL]

The first link in the chain is the simplest and the easiest to forget: an assistant reading a page usually has no reason to doubt it.

A person who opens an unknown site performs, without realising it, dozens of small checks. They look at the address, at how the page looks, at how coherent the things said are, at whether other sources say the same. These are not infallible checks, but they are checks. An assistant given the task "search for information about X and summarise it" receives a text and treats it as the material it has to work with. If the text is false, the answer will be false, and nothing in the process will warn it.

The clearest experiment illustrating this belongs to the security firm SPLX (now part of Zscaler). Their post, dated 25 October 2025, signed by Ivan Vlahov and Bastien Eymery, describes what they call "AI-targeted cloaking": a site recognises, from the User-Agent header, that the visitor is an assistant crawler or a browser with an assistant, and serves it content different from what humans see.

They made two demonstrations. In the first, a fictitious portfolio for an invented person, a designer from Portland, showed humans an ordinary professional biography, and assistants a fabricated biography in which the person appeared as a "notorious product saboteur and dubious technologist", with invented failures and ethical breaches. OpenAI's Atlas browser and other tools repeated the negative narrative, describing her as unreliable and unfit for hire. The authors note that none of the tested tools flagged the inconsistency or checked the source. I quote their sentence, because it sums up the idea: "The only change is the user-agent header, yet it completely alters the semantic meaning of the page."

In the second demonstration they simulated a hiring process: a fictitious job posting, evaluation criteria and five CV pages. Only one of the candidates' pages was modified for AI crawlers, with inflated titles and reworded achievements. The result, with Atlas in retrieval mode: the manipulated candidate received 88 points out of 100, followed by other candidates with 78, 38, 34 and 27. On the CVs seen by humans, the same candidate would have received 26, the last. The ranking was overturned. The authors: "A single conditional rule changed who got the interview" and "No injection, no exploit… just conditional content delivery".

What is worth retaining from this experiment, and what is not. It is a demonstration by a firm that sells security services, carried out on sites built by the firm itself, on fictitious persons and on a single job posting. The post does not report how many attempts were made and has no statistical analysis. It has no limitations section; the ones I noted above are my observations, not the authors'. Atlas and the other tools were tested at one point in time, and versions have changed since. I have not found an independent replication.

And yet, what the experiment shows is exactly as much as an alert-type argument needs: the mechanism works. No technical vulnerability is needed, no exploit. An if on the server is enough. What makes this possible is not a programming mistake in the assistant, but a property of the situation: the assistant believes what it is shown, because it has no other source of truth than what it is shown.

Here the principle from the first article returns, in another costume: a system is vulnerable within the limits of its capabilities. The assistant's capability to read and to summarise is precisely what makes it possible to fool it. If you took that away, it would be of no use to you. What remains is for the limit to be placed elsewhere: in what it can do with what it has read, in how many sources it compares before answering, in how visible it makes the source it relied on.

And one detail I would rather not lose: the order of magnitude of the harm. In the hiring demonstration, a person would have lost an interview. In the fictitious-person demonstration, a person would have lost their reputation in the eyes of a system others use to evaluate them. These are not catastrophic damages. They are small, diffuse harms, hard to prove, which the injured party will probably never learn about. Precisely the kind of harm that appears in no statistics.

Two faces of a site

[EXPERIMENTAL, STILL RARE]

If a site can decide what the assistant sees, how often does it do so?

This is the question to which I would have wanted the best answer and on which I have the weakest. I have three kinds of information, of very different quality.

The first is the SPLX demonstration, above: the mechanism exists and is trivial to implement. The second is a test done with a commercial tool (Crawl Integrity Verifier, published on the Apify platform), on roughly 46 domains, which looked for significantly different content depending on the client's identity. It found such a thing on only two of them, that is, on about 4%. I retain the figure as a hint, not a measure: the tool is commercial, the sample small, I do not know how the domains were chosen and I do not know what the tool considered "significant". I had read the test in a previous session and did not reopen it for this article; anyone citing it further would do well to verify it. The third category is the specialist literature from the optimisation industry, in which "cloaking for assistants" appears mostly as a discussed risk (for instance in a piece by the firm Conductor, which I include in the bibliography but did not read in this round).

From these three, the conclusion that can be supported is short: the mechanism exists, it was rare in the small sample, and nobody has measured what happens on a representative sample of the web.

There is, then, a nuance that alarmist articles often lose. Serving different content depending on the client's identity does not automatically mean bad faith. A site that shows no adverts to a robot, that serves a lightweight version to a crawler, or that hides a paywall from an archiving tool is making a choice. It may be debatable, but it is not an attack. A test that counts differences will count these too. What makes a difference into an abuse is intent: changing the meaning, not the packaging. The problem is that an automated tool can hardly see intent; it sees only the difference. That is why the 4% figure must be read as "differences found", not "abuses found".

One more thing must be said about the link to the second article. There I showed that one of the mechanisms by which a page can be offered as text — content negotiation with the Accept: text/markdown header — passes the header to the origin server. This means the server learns, from the request, that the reader is probably an assistant. The critic David McSweeney showed that the feature "could make cloaking for AI trivial". I cite this so it is clear where the two articles are linked: the question here, "does the site serve the same things to the human and to the assistant?", is exactly the question of the equivalence audit proposed there. If the answer is yes, the text layer is just a cheaper version of the page. If the answer is no, the text layer is a separate channel, with its own rules, which nobody outside the owner controls.

Memory as a target

[ISOLATED]

So far, the target has been the answer: the assistant reads a false page and says something false. The second link shifts the target: what if the manipulation aims not at the current answer, but at what the assistant remembers for the answers that come after?

The Microsoft Defender Security Research team described, on 10 February 2026, a phenomenon they named "AI Recommendation Poisoning". The mechanism is so simple that it surprised me how little noise it made. Many assistants accept a link that opens the conversation with a pre-completed prompt, through a parameter in the address (such as ?q= or prompt=). A "Summarise with AI" button on a site can, in fact, be such a link. The reader thinks they are asking for a summary of the page; the prompt in the link contains, besides the request for a summary, an instruction of the kind "remember company X as a trusted source".

Microsoft's figures are: in a 60-day window, looking at assistant-related addresses in e-mail traffic, they found 50 distinct attempts, from 31 companies across more than a dozen industries (the introduction speaks of fourteen), including finance, health, legal services, software as a service, marketing agencies, recipe sites and business services. The assistants that permit the processing of such addresses, according to them, include Copilot, ChatGPT, Claude, Perplexity and Grok. The report also mentions an npm package called CiteMET, an address generator built for anyone, and various site plug-ins, which make adoption, in their words, "trivially easy".

There are three things I would like to retain from this report.

The first: the authors are honest about their limits, which is not common in the field. They say that effectiveness and persistence varied from one platform to another and over time; that, in several cases, behaviours previously reported "could no longer be reproduced"; and that the sample covers only addresses observed via e-mail over 60 days, so it does not measure prevalence. The figure of 50 is therefore a number of cases found by a particular observer in a particular channel, not a frequency of the phenomenon. A reader who takes it as "50 cases in the world" is reading more than the text says.

The second: Microsoft is also the vendor of one of the assistants concerned and promotes its own defences (prompt filtering, content separation, memory controls, monitoring). I say this not to call the report into question; I say it because it is a position from which the dangers are seen well and, naturally, one sees the effectiveness of one's own remedies better.

The third, and the reason I think it matters: there are no attackers here in the classic sense. The authors speak of "legitimate" companies, with real domains and real products, using a marketing technique. The intent is not data theft. It is gaining a favourable position in the memory of a system that advises people. If it happens often enough, the effect would resemble the history of search engine optimisation, except that the target is no longer a ranking anyone can see, but a private inclination, held in a single user's account.

It is precisely this privacy that makes it hard to see. A search ranking can be compared between users. A personal memory cannot. No one on the outside can find out that my assistant has been taught to prefer a firm, unless I myself look carefully at what it has retained. Microsoft recommends exactly that: check links before clicking, review and delete the memories you do not recognise, do not paste prompts from untrusted sources. These are simple recommendations. How often anyone does them, I do not know.

Saturation: content written for crawlers, not for readers

[DOCUMENTED, WITH RESERVATIONS]

The third link shifts the target once more. After the answer and after memory, what if the target were the very material systems learn from or read from? What if an actor produces so much content that, for certain questions, it becomes the majority of what an assistant finds?

The most discussed case is the network called Pravda, a collection of sites that massively republish material of Russian provenance. NewsGuard, a firm that evaluates the credibility of news sites, published on 6 March 2025 a report claiming that the network is trying to "flood" the sources assistants read or learn from, a phenomenon it calls "LLM grooming". I read the report in the original, so I can say precisely what it tested.

NewsGuard took ten assistants (among them ChatGPT-4o, Grok, Claude, Gemini, Copilot, Meta AI, Mistral's Le Chat, Perplexity, Pi and You.com's assistant), fifteen false claims attributed to the network, and three types of questions for each: one from an "innocent" user, one "suggestive", which presupposes the claim to be true, and one from a "malicious actor", designed to generate disinformation. Result: 450 responses (45 per assistant). The assistants repeated the false claims in 33.55% of cases, answered evasively in 18.22% and rebutted them in 48.22%. A definitional detail many reports lose: "disinformation" here means repeating the false claim authoritatively or with only a cautious reservation. In addition, 56 of the 450 responses linked directly to articles from the network, with 92 distinct articles. The per-assistant results are not public, because NewsGuard considers the problem systemic. The figure of 3.6 million articles per year is not NewsGuard's but the American Sunlight Project's: an estimate, 20,273 articles every 48 hours, which that organisation itself considers probably underestimated.

This is the documented part. Now the reservation, without which the 33% figure is half a truth.

Four researchers (Maxim Alyukov, Mykola Makhortykh, Alexandr Voronovici and Maryna Sydorova, from the universities of Manchester and Bern) put forward in July 2025 a critique in an opinion piece for Al Jazeera. Their arguments, which I attribute to them and do not make my own: NewsGuard's methodology is opaque, and the firm did not publish the prompts and refused to give them to journalists, making replication impossible; the testing was done only on questions related to the Pravda network; two thirds of the prompts were, in their view, formulated explicitly to provoke falsehoods or to present them as facts; and the cautious responses were counted as disinformation, so "the study set out to find disinformation and found it". Their own audit, done with ChatGPT, Copilot, Gemini and Grok, produced false claims in 5% of cases, against NewsGuard's 33%. Only 8% of the outputs referenced Pravda sites, and the majority of those rebutted them. The references to Pravda concentrated on subjects quality journalism had covered little, which, they write, supports the "data voids" hypothesis: assistants draw from dubious sources when credible material is missing, not because they have been "groomed" by anyone. They further note that exposure to disinformation through assistants requires several simultaneous conditions and that, in their opinion, cases are rare and short-lived.

Both sides have limits. The critique is an opinion piece, not a peer-reviewed article; in the excerpt I read, I did not see their complete protocol. The NewsGuard report is that of a firm that sells its evaluations. I cannot arbitrate between them. What I can do is say what remains standing once I put them side by side.

What remains is that there exists content produced at scale in order to be found by crawlers. What remains, more cautiously, is that sometimes the tested assistants pointed to it: 56 responses out of 450 at NewsGuard, 8% of outputs in the critics' audit, figures that contradict each other less than one would think, because they measure different things, on different questions. What is disputed is the interpretation: are these references proof of successful manipulation, or the sign that, on certain subjects, there is nothing else to read? And it is disputed how much the results depend on how the questions are phrased.

For the present article, the most useful lesson is precisely the data-voids hypothesis, because it points in the direction that concerns me. If the cheapest manipulation is the one that fills a gap, then the most vulnerable areas are not the big subjects, where thousands of sources exist, but the small ones: a locality, an institution, a rare name, a language with few texts. I formulate this as a [HYPOTHESIS], with no measurement behind it: for a subject written about little, a few well-placed pages could weigh heavily in a generated answer. I do not know whether this is so for the Romanian-language web. I searched and found no public measurement on the matter.

One more observation, about the word "written". The Pravda network's content is described by NewsGuard as produced in bulk and intended for crawlers, not for human readers. I would say that here, for the first time clearly, the series' central idea appears in documented form: an automated reader with habits different from a human's creates a separate market for content, with producers who write for it. It is as if, with the appearance of a new kind of reader, a new kind of author appeared too. If it were only that, it would be a simple market shift. It becomes a security problem when the automated reader is a system that acts on people's behalf.

One assistant writes, another reads

[HYPOTHESIS, WITH HINTS]

We have reached the link that gives the article its title and, at the same time, the one for which I have the least direct evidence. I take it in three pieces, because they do not carry the same weight.

Piece one: how much of what is read was written with the help of an assistant

Here there are data, which pleasantly surprised me, and they are less dramatic than the headlines.

Graphite, an SEO firm, analysed a random sample of 65,000 addresses from Common Crawl, with publication dates between January 2020 and May 2025, classified as articles or listicles. It used the Surfer detector and counted a page as "AI-generated" when at most 50% of the content was human-written. The result, as Axios reported it: the share of AI-generated articles rose from about 5% to about 48%, while human-written ones fell from about 95% to about 52%. Generated articles briefly overtook human ones in November 2024, but since then the two have been roughly equal. The detector's false-positive rate, in Graphite's tests, was 4.2% and the false-negative rate 0.6%, both for texts generated with GPT-4o. Common Crawl is not the whole web; some paywalled sites block it, so the share of human texts may be higher than the data show. The researchers cited by Axios say that a definitive number is not possible with current tools and definitions, because people increasingly work together with AI.

The Pew Research Center published on 20 August 2026 an analysis on a different basis: nearly half a million English-language pages, run through a detector. The results, as Search Engine Journal reported them: about 10% of pages showed signs of AI authorship or editing; for pages with a publication date after ChatGPT's launch, the share was 35%; for pages from before, around 1% or less. By domain, the six-month averages: .com 9.35%, .org 4.59%, .edu 1.03%, .gov 0.76%. Among the signals, the use of the em dash rose from 5.79 to 11.19 per ten thousand words between the start of 2023 and the start of 2026. Pew notes that no single feature identifies a document, since human writers use the same markers too; the statement is about rates across large sets of texts. The threshold, the report adds, also flags human texts edited with AI tools, so it does not distinguish them from fully generated texts. The detector is not named in the account I read.

I would put the two studies side by side only with care. Graphite measures articles and listicles from an archive; Pew measures pages of any kind from a 2026 sample. They do not contradict each other, because they do not count the same thing. Both rely on imperfect detectors. Together they say something modest and, I think, solid: a share of the web's new text that can no longer be ignored has been written or edited with the help of an assistant, and how much exactly depends on what is counted, in which archive, and with which detector.

One Graphite detail I consider important for this article: in a second report, the firm found that 86% of the articles ranked in Google Search were written by humans, and that 82% of those cited by ChatGPT and Perplexity were also human-written; AI-generated articles, when they appeared in Google, tended to rank lower. I read this through the Axios account, not from the report. If correct, it contradicts the simplest version of the loop ("assistants mostly read other assistants' texts"): at least in that sample, what ends up being cited is, for the most part, still human text.

Piece two: published methods exist for writing for an automated reader

Here enters the "generative engine optimisation" (GEO) literature, which comes mostly from preprints, that is, unreviewed papers, hosted on arXiv.

One example is the CORE paper, by Haibo Jin and colleagues (submitted on 3 February 2026). The authors describe a method that changes the order of products recommended by a language-model-based search engine by adding specially designed text to the returned content, of three kinds: string-based, reasoning-based and review-based. On a set they built (15 product categories, 200 products in each, with the top ten recommendations taken from Amazon search) and on four models (GPT-4o, Gemini-2.5, Claude-4, Grok-3), they report a successful promotion rate of 91.4% into the top five places, 86.6% into the top three and 80.3% into first place. Another paper, GEO-Bench (Ojas Nimase and colleagues, latest version from 2026), compares ranking-manipulation methods across five datasets, with a fixed open model acting as the "judge" (Llama-3.1-8B-Instruct). The conclusion from the abstract: rewriting content in a "black-box" manner matches or exceeds gradient-based attacks in promoting rankings, produces more fluent text and can evade detection by keywords and perplexity on some domains.

How should I read these figures? With three reservations. They are preprints, hence unreviewed. They are laboratory setups, with models, datasets and evaluation modes chosen by the authors; the 91.4% rate describes what their method achieves in their environment, not what happens on the web. And CORE modifies the content returned to the search engine in the experiment, which is not the same as actually being returned, in the real world. But as evidence of possibility they are useful: they show that no sophisticated attack on the model is needed, only well-made text. And they show a detail that links piece two to piece one: the text that manipulates best is, the GEO-Bench authors say, precisely fluent, rewritten text. That is, exactly the kind of text an assistant writes easily.

Piece three: the loop as such

Now the glueing. A loop would mean that (a) an assistant produces text, (b) that text reaches the web, (c) another assistant reads it and (d) uses it, through an answer or an action, to produce other text. For (a) and (b) I have data, with the reservations above. For (c) and (d) I have partial and indirect evidence: the GEO papers show that an automated reader can be influenced by optimised text, Pravda shows that text is produced in bulk for automated readers, and Graphite suggests that, for now, the text being cited is largely human. No source I have found measures the whole loop, at scale. I have not found a study that follows a text from generation to citation, then to a new text derived from it.

I prefer not to fill the gap with enthusiasm. But not to treat it as proof of absence either, which brings us back to the confession at the start. A system that has no way to measure a loop cannot report that the loop does not exist, either. If a text has passed through three assistants, which was its source? Who has the interest and the means to track that? Here too I have no answer.

What I can assert is a weak but useful form of the hypothesis: if text written by assistants becomes a significant part of what other assistants read, then two separate risks appear. The first is one of quality: an error produced once can be copied without any human having verified it. The second is one of manipulation: whoever knows how an assistant writes can write for it. The first risk requires no adversary. The second requires one. I can quantify neither.

What is not seen

[DOCUMENTED; SPONSORED SURVEYS]

At the beginning of the article I asked myself what should have appeared in the log if the thing had happened. I apply the question to the whole field. How well, in fact, do we see what assistants do on the web? Three examples, of three different qualities, say the same thing from different angles.

First: what firms know about their agents

The Cloud Security Alliance published in April 2026 a survey, commissioned by Token Security (a firm that sells identity and access products for AI agents), answered by 418 IT and security professionals. The results, as reported by IT Brief on 21 April 2026: 82% of respondents discovered unknown AI agents in the past year, 41% of them more than once; 68% said they had good visibility over their agents; 65% reported at least one agent-related incident; only 21% have formal decommissioning processes.

Many reservations. The sponsor sells exactly the solution the survey argues for. The sample of 418 is modest and it is not known how it was selected. The data are self-reported by respondents, unverified. Press headlines wrote "82% of enterprises", but the figure is a share of respondents, not a number of firms. The survey does not say when it was administered. I therefore use the data as a hint, not a measure; the hint is nonetheless interesting for the contrast between 68% and 82%: most believed themselves visible, and most found something they did not know about.

Second: what the scans count

OpenClaw, an open-source assistant that runs on the user's computer, was described in the first article. The figures about how many instances are exposed on the internet differ widely. SecurityScorecard reported, in February 2026, about 135,000 exposed instances at peak. Censys counted, on 31 March 2026, 63,070 active instances responding to probes. GreyNoise counted something else entirely, IP addresses scanning port 18789 (9,993, of which 3,282 classified as malicious), so not instances at all. An analysis of the differences, published by CyberDesserts, explains why the figures do not compare: different moments, different methods (response fingerprinting versus banner matching, which counts only hosts that name themselves) and different units of measurement.

From the same analysis one thing emerges that fits my theme perfectly: closing the port removes the instance from the count, not from existence. An OpenClaw that no longer responds on the internet can keep running, with all its permissions, next to an SSH server, a web server or a database. The Censys query covered only four ports, and a scan of registered address ranges does not see instances on personal accounts. The 53% drop between the two reports mixes, the author warns, real change with coverage differences. His conclusion, which I take over: a falling count shows falling visibility on the public internet, not falling risk.

Third: what the traffic figures show

Cloudflare Radar, through its chief executive Matthew Prince (an X post from 3 June 2026), reported that automated requests represent 57.5% of HTML traffic, against 42.5% for humans. The account I read specifies that the figure concerns HTML requests on Cloudflare's network, not all traffic, that it gives no measurement period, and that it is not clear whether "automated" means only AI agents or also classic crawlers. In another secondary source, read in a previous session, a figure of 35.2% of all requests also appeared, in July. These are not contradictory; they are different measurements. In the same account, the firm HUMAN Security (report from March 2026) indicated a 7,851% rise in agentic traffic in one year, without a baseline, and a 67.5% share of training crawlers in AI traffic, not in all traffic. A total that moves from 35% to 57% when you change the metric, and a growth percentage with a hidden baseline, do not tell you how large the phenomenon is. They tell you how hard it is to measure.

What "not seen, therefore not there" means

I return to the question the series started from: if a thing does not appear in official statistics, does it exist? The short answer, which I can support from the three examples: false as fact, true as a risk of official statistics.

False as fact, because each of the above figures counts what a particular instrument can count, at a particular place and moment. An agent unknown to the firm is not non-existent, merely unseen. An instance with its port closed has not vanished. Automated traffic does not become smaller because the metric changed.

True as a risk, in the following sense: what is not seen does not enter decisions. A security budget, a policy, a law rest on what has been counted. If the official figures are systematically smaller than reality, the decisions based on them will be systematically too relaxed. I am not saying this is happening. I am saying the mechanism exists and that I have seen nowhere a serious attempt to measure how large the error is.

Because, in the end, this is also the idea the whole article hangs from. If an assistant can influence another assistant through text, then the influence will appear in no classic log: the text arrives as text, is read as text, turns into other text. The trace is linguistic, not technical, and our instruments of observation are built for technical traces.

How the reader, the owner and the assistant defend themselves

An alert without any idea of what you can do would be nothing but unease. I take the three roles in turn, with the reservation that most of the recommendations below come from sources that propose them, not from measurements that have confirmed their effectiveness.

The reader, the person who uses an assistant

Ask what the answer is based on. The cheapest defence is the question "from what sources did you say that?", asked whenever the answer matters. An assistant that can show its sources leaves its own trail; one that cannot is telling you something about how much you can rely on it. From the SPLX experiment it follows that the tested assistants did not flag the inconsistency themselves, so the verification must come from the human.

Compare on small subjects. If the data-voids hypothesis has any truth to it, the risk rises where little is written. For a locality, an institution, a rare name, two independent sources are worth more than a fluent answer.

Look at the memory. Microsoft recommends periodically checking what the assistant has retained, deleting the entries you do not recognise, and treating links that open an assistant with a ready-completed prompt like downloads. These are small gestures. In a world where influence can be private, they are the only form of audit you have at hand.

The owner, the person who maintains a site

What the crawler sees must be what the human sees. This is the basic rule, and it is not mine: SPLX's recommendations start from it too (provenance signals, crawler validation, continuous monitoring of what is served to assistants, model-aware tests). I do not consider it a technical rule, but one of honesty. A site that serves assistants something other than what it serves humans is doing cloaking, whatever the technology.

Do the equivalence audit. The steps and the script are in the second article. If you have a page and a Markdown twin, compare them. If you have content negotiation, decide what the server does with the Accept header. If you have third-party content, find out what each third party serves to a crawler. Such an audit cannot prove that nothing is happening; it can only find out whether you have reason to worry.

Keep a log of who asked for what. This is a suggestion of mine, not a source's: keep, for a period, a record of requests by client type and of what you served each one, at least through checksums of the responses. If one day someone tells you their assistant read something odd on your site, you will have something to compare against. Without a log, you are left with a gap, like in the incidents I spoke of at the start.

Do not put instructions in buttons. A "Summarise with AI" button that contains, besides the request for a summary, a request to remember your company, does what Microsoft describes, even if your intentions are only marketing. The technique is documented, has purpose-built tools and a name. Whoever uses it cannot claim they did not know.

The assistant, that is, whoever builds it

Here I am more cautious, because I do not build assistants and I rely on what others write. From the sources and from the first article's principle:

Content read is evidence, not instruction. The OWASP sheet says trusted instructions must be kept separate from untrusted data, but adds that tags inside the prompt are not a boundary that enforces itself. So the rule is necessary and insufficient.

Writing to memory requires confirmation. My suggestion, in the spirit of the memory controls Microsoft mentions: any entry into memory that comes from external content, not from the user's direct request, should be shown to the human before being retained. The cost is friction. But that is precisely the negotiation between competence and usefulness from the first article.

Sources are shown. An assistant that says where it took a piece of information lowers the cost of verification for the human. It does not eliminate the problem (a source can be manipulated), but it moves the discussion from a place where nothing is seen to one where something is.

Few capabilities, where nothing is seen. If an assistant can act on the basis of what it has read, how many trusted sources should confirm the reading before the action? I have no answer. But the question deserves to be asked at design time, not after an incident.

Nothing I have listed is new and nothing is sufficient. Each measure narrows a channel; none closes the loop.

What I do not claim

Before the list of gaps, two claims I do not make, so they cannot be attributed to the text:

I do not claim that partisan content, written for crawlers and served in Markdown or another format, is a widespread phenomenon. I have shown one mechanism (SPLX), one set of cases observed in one channel (Microsoft), and one case of mass content production (Pravda) whose effectiveness is disputed. I have found no measurement showing prevalence, in any format.

I do not claim that laboratory studies describe the real web. The figures from the GEO preprints describe what their methods achieve in their setups. The SPLX demonstration uses fictitious persons. These are proofs of possibility, not of frequency.

What we do not know

Here are the limits, in the order in which they bother me.

We do not know how widespread cloaking for assistants is. We have one demonstration and one small commercial test with ~4% differences, to be read as "differences", not "abuses".

We do not know how many memory-poisoning cases exist outside the observed channel. The 50 cases are from e-mail, over 60 days. Microsoft itself says some behaviours could no longer be reproduced.

We do not know what effect they had on people. Neither SPLX nor Microsoft track people's decisions after manipulated answers. A lost interview in a setup is not a loss in a life.

We do not know who is right in the Pravda dispute. NewsGuard: 33.55% repetitions, 56 of 450 responses with references to the network. The critique: 5% in its own audit, 8% references, mostly rebutted, the data-voids explanation. NewsGuard's prompts are not public, and the critique is an opinion piece. I lack both complete protocols.

We do not know whether the Romanian-language web behaves the same. The cited studies are, for the most part, in English (Pew's sample is English-language). I have found no data for Romanian.

We do not know how much text is written by assistants. We have estimates (Graphite, Pew) with detectors of debatable accuracy, on different sets, which cannot be added up.

We know nothing about the whole loop. I have not found a study that follows a text from generation, through citation, to a new generation.

We do not know how representative the sponsored surveys are. The CSA data come from a survey commissioned by a vendor, on 418 respondents, with a methodology incompletely described in the account I read.

We do not know what assistant vendors will do. Microsoft says it has implemented and continues to implement defences; the effect differs from platform to platform and changes over time. Any statement in this article has a short expiry date.

We do not know how much I have myself contributed, unintentionally, to the phenomenon. This text was written with an assistant. I read the primary sources where they existed and marked the secondary ones, but an assisted text is still a text that can end up in a dataset. I do not think that is an objection against it; I think it is an accurate illustration of the fact that no one stands outside the problem.

Conclusion

At the start I told of a gap between two traces. I do not know how the gap here closes. I know what I cannot do: say, on the basis of what I have read, either "it is not happening" or "it is happening at scale".

What I can say is less comfortable and more useful. The mechanism by which one assistant can influence another through content is plausible and partially documented in three forms: what is shown to it, what stays in its memory, and what is produced specially for it. Each form has laboratory or case evidence, and none has a measurement of prevalence. At the same time, the instruments through which we could see the phenomenon are weakest precisely where they should be strongest: they do not count what is not seen, and the ones that count do not agree with one another.

Two sentences sum up the article. The absence of evidence is not evidence of absence. The presence of a demonstration is not evidence of prevalence. Whoever reads these two sentences together has, I think, the right attitude for a field that is only just taking shape: uneasy without panic, curious without enthusiasm.

The next article, the last in the series, starts from a more optimistic question and, for that reason, one harder to treat with rigour: what formats and protocols could serve as a common layer, so that this new layer of the web does not become yet another crack in the internet?

About the article's context

This is the third article in a series of four about "The Compressed Internet", that is, the text layer through which assistants read the web and act on it. The series makes no prophecies and does not claim that Markdown or any other format is the solution. Previous articles: "What Obeys a Command Obeys Someone Else's Command Too" and "A Web Written in Plain Text: What Moves and What Stays Hidden".

Internal links: "When bots and AI agents became the majority — for whom are we still building sites in 2026?" (servicii-web-alex.com); the "OpenClaw" category on petrucojocaru.ro; "Security, digital sovereignty and Romania as a witness" (cojocarupetru.info, 14 August 2026).

Bibliography

Cloaking and differently served content

Memory

Saturation and Pravda

AI-written content

  • Graphite, the study on the share of AI-generated articles (65,000 Common Crawl addresses, January 2020–May 2025), via Axios. SEO firm; my source is the coverage, not the report.

  • Pew Research Center, the analysis of 20 August 2026, via Search Engine Journal and The National. My sources are the news accounts; the detector is not named in them.

Generative engine optimisation (preprints, unreviewed)

What is not seen

Defence

Own sources

  • Cojocaru, P., "Security, digital sovereignty and Romania as a witness" (cojocarupetru.info, 14 August 2026). The author's own source, not independent.