We almost deployed an AI debugging agent.
Then we found a critical CVE.

When our client’s team evaluated Sentry Seer, the appeal was clear: it could automatically triage production errors, propose fixes, and open pull requests. For a small engineering team, that promised meaningful time savings. We decided not to proceed with the rollout after a serious security vulnerability was disclosed just days before launch.

In June 2026, Tenet Security disclosed “agentjacking”: an attacker sends a forged error event through a public Sentry DSN, and when a developer later asks their coding agent to look at open Sentry issues, the agent reads the event through Sentry’s MCP server and follows the attacker’s instructions. Sentry acknowledged the report but declined to fix the root cause, calling it “technically not defensible” at the platform level. CVE-2026-90999 is the same weakness on a different path. Agentjacking needed a developer to prompt the agent. Seer’s automated handoff removes that step, so forged telemetry can reach a privileged coding agent with no human involved at all.

It would be easy to file this under “vendor security incident” and move on. But this is structural, and applicable to any AI agent that consumes external telemetry and takes automated action.

Most security reviews focus on the model and the endpoint. Once an AI system can take action, the path from incoming data to execution becomes another part of the system that needs a security review.

In this case, that pipeline had four stages:

• Telemetry ingestion — a public DSN accepted events from anyone
• AI processing — Seer generated a root-cause analysis
• Agent handoff — the analysis was embedded into a prompt sent to a coding agent
• Execution — the agent ran code in a privileged environment with source repo access

Each stage assumed the previous one had validated its input. None enforced that assumption end-to-end. The problem was not isolated to one component. It came from the way untrusted data moved through the entire workflow.

The CERT/CC advisory describes it plainly: fabricated events traverse multiple trust boundaries, transforming from untrusted telemetry into instructions the privileged agent executes.

We built a short checklist for any AI agent that takes automated action:

Check	What to ask
Inputs	Are all inputs authenticated? Can an external actor trigger the pipeline without credentials? Public endpoints such as DSNs, webhooks, and forms should be treated as untrusted entry points.
Privileges	Does the agent execute code? In what environment? With what scope? If the answer is “our infrastructure, with production access,” the bar for input validation is much higher.
Handoffs	Every stage between input and execution is a trust boundary. Are those boundaries enforced, or assumed?
Triggerability	If an unauthenticated user can trigger the workflow, every stage of that workflow needs to be included in the threat model.
Blast radius	If malicious input reaches the agent, what can it do? CERT/CC notes that successful exploitation gives access to connected source repositories, and allows actions permitted by the coding agent’s credentials.

The questions are easier to answer before launch than after. Adversarial testing of what an agent does with hostile input is part of our AI agent testing and evaluation work, and the output-schema, whitelist and human-approval pattern is the one we describe in our agent guardrails case study.

Our Trust & Safety page sets out the controls we apply when we build agents that act on a client’s systems. If you’re vetting a vendor rather than building, start with what to check before trusting an AI vendor with your data.