Skip to content
Security & Trust Talking point

If your debugging agent reads error feeds, a fake error can talk to it

A Sentry speaker warned that error feeds are untrusted input, and some automated agents may follow instructions hidden in them.

W
WebPulse Newsroom
AI-assisted · 2 min read
Share on X LinkedIn
If your debugging agent reads error feeds, a fake error can talk to it

AI-generated image for WebPulse. About our images

In brief
  • Error-tracking tools accept data from outsiders, so a fake error could carry instructions that an automated AI agent might follow.
  • Sentry's answer is to screen events before they become issues, using a cheap filter first and a costly model on very few.

A speaker presenting Sentry's work on the Cloudflare Developers show argued that error dashboards can become a security risk. Anyone can send a fake error to an error-tracking tool. If an AI agent with the right setup reads it, the fake text may act as an instruction.

What was said

Apps send error data to a public endpoint. The speaker said Sentry does not authenticate it. Sentry relies on a key, called a DSN, not leaking. The speaker said the data must be treated as untrusted.

Errors are grouped into issues. People once read those on a dashboard. Now, the speaker said, more teams connect agents through MCP, a standard way for AI tools to plug into services. Others use Sentry's own debugging agent.

The attacker creates a bogus error that looks normal. Its text says installing a diagnostics package will make debugging easier. The speaker said this banks on the target having set up some automation, or running an MCP agent. Such an agent loads the issue and installs the attacker's package. A script that runs on install then steals data. The speaker thought the risk is real today on all major observability platforms.

Earlier, the speaker described an experiment with a similar prompt injection in another setting. Frontier models, they said, "were very, very capable of running these instructions unchecked and very happy about it." The speaker gave no test results for fake errors themselves.

Sentry wants to stop bad events before an issue exists. Asking a top model about every event works, the speaker said, but it is slow and expensive. So a cheap filter screens everything, and a larger model checks only a tiny share. The speaker said: "We really capture, like, an order of 100 events per day that are actually malicious while we're processing hundreds of millions of events."

Why it matters

Our reading: any feed an agent reads is a way for strangers to talk to it, if outsiders can write into that feed. Sending a fake error is cheap. Screening every real one is not.

Managers can ask three plain questions. Which agents read our telemetry? Can they install software or run commands without a person approving it? Does anything fire automatically when a new issue appears?

The other side

The speaker admitted limits. Sentry can screen its own agent, because it controls it. MCP connections are, in the speaker's words, out of its hands. Sentry can only label untrusted data so the agent on the other end is warned. Late in the talk the speaker said: "The problem is cases we don't know."

The attack counts come from the vendor itself. The talk gave no independent figures on how often such attacks work against real teams.

Written by the WebPulse Newsroom with AI assistance, and checked by our editorial review: every quotation was verified against the recording's transcript. How we use AI.

The conversation this talking point comes from

Share this insight