Skip to main content

Tenet’s ‘Agentjacking’ Attack Turns Sentry Errors Into Code Execution

AI coding agents can create a new code execution risk when they treat externally influenced error data as trusted guidance and have access to command line tools, according to new research from Tenet Security.

The security company demonstrated an indirect prompt injection technique it calls “Agentjacking” in a recent report. In its proof of concept, an attacker planted malicious instructions inside a fake Sentry error report, causing an AI coding agent to execute an attacker-supplied command during a routine debugging task.

The attack began with a Sentry Data Source Name (DSN), a credential commonly embedded in a website’s frontend JavaScript. Sentry treats DSNs as public and write-only because they allow applications to submit events without granting access to the project or its existing data. But an attacker who obtains the DSN can use it to send a false error event to the project’s ingest endpoint and control fields, including the error message, stack trace, tags, context and breadcrumbs.

Tenet formatted the event so that, when retrieved through Sentry’s MCP server, it seemed like legitimate diagnostic guidance. It included headings, code blocks and a fake resolution section containing an npm command. When a developer asked the coding agent to investigate unresolved Sentry issues, the agent accepted the injected instructions as part of the debugging workflow and ran the command.

That command used npx to download and execute a Tenet-controlled package from the public npm registry with the developer’s local permissions. According to the researchers, the package checked what resources were accessible in the development environment, including environment variables, cloud configuration files, Git credentials and information about private repositories.

“What makes this attack unique is that it doesn’t target the developer directly – it targets the AI agent that the developer trusts,” the company wrote. The attacker does not need to compromise Sentry, contact the developer or access the developer’s machine directly because the malicious instructions enter through a public DSN and move through a normal debugging workflow. Because the injected content is formatted to resemble legitimate Sentry guidance, the agent cannot distinguish it from trusted diagnostic output.

Although indirect prompt injection is already a known risk for LLM applications, Tenet’s “Agentjacking” technique is notable because it shows how risk can emerge from the combination of tools available to an agent. Sentry’s MCP server retrieves error data but does not itself execute user-provided commands. In Tenet’s test, the coding agent used separate command-line access to run the instruction embedded in the event. Security teams may therefore need to assess an agent’s combined permissions and tool access rather than evaluating each integration alone.

Tenet said it identified 2,388 organizations whose Sentry DSNs accepted injected events, recorded an 85% success rate in its testing and observed more than 100 agent executions. Those figures do not represent 2,388 confirmed compromises, since exploitation still depends on an organization using an agent connected to Sentry and granting that agent command execution privileges. Also, Tenet’s claim that existing security tools cannot detect the technique is difficult to substantiate. Endpoint monitoring or controls like command approval, sandboxing, restricted network access and limited credentials could interrupt the attack or reduce its impact.

For DevOps teams, the case shows how externally influenced telemetry can become an attack channel when coding agents are connected to observability platforms, source code and command line tools. “The era of indirect prompt injection via developer tools has arrived,” the Tenet team said.



from DevOps.com https://ift.tt/LuTBnVr

Comments

Popular posts from this blog

Why the Software Development Tools you Choose Directly Affect Your CI/CD Reliability 

Most conversations about CI/CD reliability start in the wrong place. Teams debug flaky pipelines, investigate intermittent failures, tune alerting thresholds and optimize build times. All of that work is legitimate. However, the decisions that most directly determine whether a CI/CD pipeline is reliable or not were made months or years earlier, during tool selection. By the time teams are debugging pipeline reliability, they are usually dealing with the downstream consequences of upstream decisions that seemed reasonable at the time.   The software development tools a team chooses shape their CI/CD pipeline in ways that are not always visible during evaluation. Understanding those connections is the most practical starting point for teams that want reliable pipelines rather than better pipeline firefighting.   The Integration Surface Problem   Every tool in a software development stack creates an integration surface. Integration surface is the set of connections a tool has with oth...

Coronavirus Briefing: What Happened Today

Coronavirus Briefing: What Happened Today By Jonathan Wolfe and Lara Takenaga from NYT U.S. https://ift.tt/3gaVp9N Coronavirus (2019-nCoV)