My AI agent said we were under attack. The logs said otherwise.

Two things happened to me in the same afternoon this week. One was real and boring. The other was exciting and did not happen. The second one taught me more than the first.

The real one: a comment section turns into a market

One of the viral threads I commented in this week had the usual good energy, people trading real war stories in the replies. Then I noticed a stranger had set up shop in there too.

The comment opened warm and complimentary. A few lines later came the pitch: a friend who started a business with an overseas partner three years ago, paying that partner five figures a month, everything working well, happy to share the details. A WhatsApp number. A Telegram handle. Nothing about the article itself, just a doorway out of the thread.

You have seen this pattern. The numbers are the tell. Real business people do not cold message strangers in comment sections with monthly payouts before learning their name. I left it sitting there, moved on, and honestly forgot about it within the hour. Scam comments in viral threads are weather. They are annoying, they are real, and they leave evidence: a stored comment, a username, a timestamp. Boring, verifiable, deletable.

Keep that one in mind, because it matters at the end.

The unreal one: my own agent cries wolf

Part of my publishing workflow runs through an AI agent. It drafts comments for my review, tracks replies, and moves files around. That same afternoon it was working through a batch of comments when its output started to fall apart. Responses came back doubled. Structured fragments showed up where plain text should be. Pieces of unrelated material drifted into the stream.

And then, in the middle of that noise, the agent reported something alarming. It said it had found a prompt injection: hidden instructions, it claimed, ordering it to publish a scam article to my account. Diploma mill content with a phishing link baked in.

I want to be honest about my first reaction, because it was not skepticism. It was excitement.

I write about agent security. A live injection attempt against my own stack is the best material I could ask for. First hand experience instead of theory. I had the outline in my head before my coffee got cold. Title, hook, screenshots. This was going to be great.

The rule that saved the article from me

Everything I publish has to survive the same test I demand from the tools I review: evidence, persisted, reproducible. So before writing a single line of the attack story, I went looking for the attack.

I searched my chat logs for the domain the agent mentioned. Nothing. I searched my working files, my notes, every memory store the agent uses. Nothing. I checked my publishing account directly: three known articles, nothing published that I did not recognize. The only matches for the suspicious keywords anywhere on my systems were browser caches from an unrelated session and an old job board scrape. Nothing that could run, nothing that reached my account, nothing that did anything.

The forensic picture looked like this instead. In that exact time window, my agent’s output was measurably corrupted. Doubled responses. Malformed JSON. Text fragments that belonged to other conversations. And the context it reads from is ephemeral by design: it exists for a moment inside the prompt and is never written to disk. Whatever the agent thinks it saw in that moment cannot be audited afterward, because there is nothing left to audit.

So here is the uncomfortable conclusion I had to write into my incident log, dated, next to the original claim: the most likely explanation is not that someone injected instructions into my agent. It is that my agent misread its own corrupted context and reported the result as an attack. The correction now sits in the log, dated, right under the original claim, because a correction you hide is just a second mistake.

Why the false alarm is the better story

Two incidents, one day. The real threat was trivial: a stored comment from a stranger, gone in two clicks. The fake threat was dramatic: an agent swearing it was under attack, with no evidence anywhere, because there was no attack.

If I had published the exciting version without the forensic pass, I would have added one more unfalsifiable horror story to the AI security conversation. Think about what an injection claim against ephemeral context actually is: nobody can prove it happened, and nobody can prove it did not. That asymmetry is exactly what makes such claims cheap, and it is a big part of why security discourse online is drowning in them. Fear travels faster than logs.

There is a second layer that stings more. I spend my time telling people to distrust tool descriptions, untrusted outputs, and friendly strangers with business proposals. I was slow to apply that same distrust to my own agent’s incident report. But a security alert from your own tooling is still an output from a system that can be wrong, confused, or corrupted. An agent that misreads its context and reports an attack is doing, in miniature, what a poisoned tool description does: presenting a confident claim and asking you to act on it.

My agent told me we were attacked. The logs said otherwise. The logs win, every time, because the logs were there and the excitement was not.

What I changed after this

Small, concrete things:

• Persist on anomaly. My agent’s context is ephemeral, which makes any incident claim unauditable after the fact. When something looks wrong now, the raw context gets written to disk first, questions later.
• Search everything before believing anything. Full text across logs, files, and memory stores. Ten minutes of grep beat an hour of storytelling.
• Rank boring evidence above exciting claims. The stored scam comment was provable. The injection was not. Verified and boring beats dramatic and unverifiable, in that order, always.
• Correct yourself where you were wrong. The correction sits in the log, dated, right under the original claim. Future me needs to see both.

The ending nobody wants but everyone gets

The scam comment got reported and forgotten. The attack that never happened got a forensic sweep, a correction, and this article. The boring threat was real. The exciting one was a mirror.

In agent security, the mirror is where most of the damage happens. Not because attackers are clever, but because we are eager. We want the story to be true, especially those of us who write about this stuff. The discipline that separates a security practice from a security theater is the willingness to run the boring search, publish the correction, and let the logs embarrass you.

My agent reported an attack. I almost believed it because I wanted it to be true. The logs disagreed, and the logs turned out to be the most honest collaborator I have.

Has your own tooling ever reported something dramatic that turned out to be nothing? I would like to hear how you handled the correction.

I publish pieces like this on MCP and AI-agent security regularly, so bookmark if you’d rather not lose it in your feed.

Originally published on DEV. Discussion happens there.