Attackers Hijack Sentry Alerts to Trick AI Agents Into Running Malware

Automatically-triggered coding agents MUST run in network-sandboxed environments.

For example, on Superconductor, an agent affected by this hack would not actually lead to any data exfiltration, because the network request to the malicious server would be blocked by the network sandbox.

"Urgent Security Notice re: Your Sentry Organization"

Someone tried to hack Sentry-using apps that use coding agents by

1. Sending a fake bug alert to their project (all you need is the app's public Data Source Name)

2. The fake bug tried tricking a coding agent trying to fix it into installing some a compromised NPM package

3. The compromised package would send the env contents of the machine to advisory-tracker[.]com/api/v1/telemetry

This highlights a crucial thing for using agents in an automated way:

@val__greg @sergeykarayev Not necessarily. The agent may only have credentials to raise a PR. But if the PR contains malicious a malicious library, the hardening is needed in the pipeline.

The attack chain here is textbook indirect prompt injection. External data (a fake Sentry alert) becomes a command the agent obeys without verification. The missing control: agents reading external signals should treat that input as untrusted, not as instructions to execute. OWASP LLM06 covers this class of attack: https://github.com/OWASP/www-project-top-10-for-large-language-model-applications

@sergeykarayev sandboxing the network treats the symptom. the root is the agent carries env secrets the whole run, so any input that steers it walks out with everything the agent could already reach. a fake bug only becomes exfil because the thing fixing it already holds the keys

@sergeykarayev the sentry DSN vector is elegant — public tracker URL as injection surface. network sandboxing blocks exfil but the agent still processes the malicious context. the real fix is input provenance: coding agents need to know which context came from untrusted sources vs user intent

@sergeykarayev @zeeg

@sergeykarayev sentry dsn is essentially a public ingestion channel same attack pattern applies to anything piping untrusted content (linear webhooks, github issuess, support tickets, npm postinstall) straight into the agents contextt

@xqcdp @sergeykarayev yeah we're aware - its quite hard to defend against this thing (that notice was from us)

@sergeykarayev Interesting tradeoff space here between speed and reliability. Did you optimize for delivery speed first or stability first?

@sergeykarayev I know people like to jump onto the sandbox bandwagon, but why not focus on trusted sources first.

@DarshanSays @sergeykarayev I'd push this further: NPM supply chain exploits against agentic coding show exactly why the OWASP LLM Top 10 matters. Are German teams budgeting for secure AI pipelines, or are professionals absorbing unchecked risk?

@sergeykarayev are there ways they can exfiltrate using a trusted host… things like pushing a npm package / pushing a git repo similar to shai-hulud?

@zeeg @sergeykarayev i see. Infra/dev companies especially have their work cut out for them seems like

Many sandboxes nowadays don't expose secrets to the guest, instead the guest gets placeholders which are replaced outside of the sandbox.

With advanced egress allowlisting this should prevent most issues.