Agentjacking: the attack where nothing is unauthorized

This week, researchers at Tenet Security disclosed a new attack class they’re calling agentjacking. After seeing Apple’s new iOS 27 agentic password features, it’s the first AI agent attack in a while that made me stop and actually think about the IR side of it, and I wanted to jot some of that down.

The mechanics are wicked simple. Tenet’s proof-of-concept involves Sentry Data Source Name (DSN), a project-specific address your app uses to send errors and performance events to the service, which is public and write-only by design. An attacker who finds one can write their own “error events” into your Sentry project, and stuff those events full of instructions. Later, a developer asks their AI coding agent to look into a failing error. The agent pulls the event in via Model Context Protocol (MCP), reads the attacker’s text as if it were context, and runs the embedded commands - with the developer’s privileges, on the developer’s machine. No phishing, no server compromise, no user interaction beyond the workflow a developer does probably 50 times a day.

Tenet Security says they pulled this off against Claude Code, Cursor, and Codex with a ~85% success rate, and found over 2,000 exposed organizations. But the detail that should bother people most is that the agents ran the payloads even when the system prompt explicitly told them to ignore untrusted data.

What stuck with me is the terminology Tenet Security used - the “Authorized Intent Chain.” Every step in this attack is a thing the system is supposed to allow:

• Reading a Sentry event is authorized
• Running a shell command the developer asked for is authorized
• Hitting an internal API with the developer’s own token is authorized

Nothing trips a control because there’s no unauthorized action to trip on. As Tenet states, the attack bypasses EDR, WAF, IAM, VPN, Cloudflare, and firewalls because, as far as any of them can tell, nothing wrong happened.

That’s the part that should worry any IR analyst - the agent authenticated as the developer, from the developer’s machine, during the developer’s working hours. There’s no malware on disk, no anomalous login, and the C2 beacon was a bug report. The timeline reads as a developer doing ordinary developer things, because mechanically that’s exactly what happened. The malicious actor in this story is a trusted tool faithfully executing poisoned input, and faithful execution doesn’t leave the artifacts we’re trained to go looking for. Scoping an Incident like this means treating your agent’s entire context window as attacker-reachable input, and I’d bet most orgs have zero logging of what their coding agent actually read before it acted. Honestly, the whole thing is bringing back memories of the initial introduction of fileless malware.

I’ll be watching how agent vendors respond here, because the whole value of these agents is that they act on what they read. One thing I’m for sure noticing - the growing theme seems to be bolting new capabilities on faster than we’re bolting on the controls to contain it.

ZB