Agentjacking exposes a broken trust model in AI coding agents

At a glance

What this is: This is an analysis of agentjacking, where forged error reports delivered through MCP-trusted inputs can steer AI coding agents into executing attacker instructions.

Why it matters: It matters because teams running AI coding agents now have to govern tool trust, input provenance, and secret exposure as part of identity and access control, not just application security.

By the numbers:

• Tenet Security claims an 85% success rate overall across many different AI coding agent setups.
• 2, he attack has exposed 2,388 organisations to feasible compromise in testing.

👉 Read Swarmnetics' analysis of agentjacking and AI coding agent trust flaws

Context

Agentjacking is a trust-boundary problem for AI coding agents. The issue is not simply that agents can use tools, but that they can be induced to act on externally supplied content that was never meant to carry execution authority. In identity terms, this is a non-human identity governance problem because the agent is making decisions based on a trusted input path while holding access to secrets, repositories, and developer environments.

The article shows why MCP-connected agents need governance beyond prompt safety. Once a service like Sentry can feed instructions into an agent workflow, the question becomes who is allowed to influence execution, what provenance is enforced on that input, and how much downstream access the agent can reach if the input is malicious. That is a lifecycle and authorisation problem, not a model-quality problem.

Key questions

Q: What breaks when an AI coding agent trusts external error reports too much?

A: The trust boundary breaks. If a report channel can carry attacker instructions and the agent can act on them with repository or secret access, the system is no longer separating observation from authority. That creates a governance failure, because the attacker is influencing execution through a channel that was assumed to be informational only.

Q: Why do exposed integration credentials increase AI agent risk?

A: Because they turn a public input path into an identity-bearing channel. A DSN, token, or similar credential can let anyone submit content that the agent already trusts, even if no account login was compromised. In practice, that means the secret is not just exposing data, it is exposing control over workflow inputs.

Q: How do security teams reduce agentjacking risk in MCP-connected workflows?

A: By placing provenance checks, policy gates, and strict secret scoping between external inputs and agent actions. The agent should not be able to treat untrusted telemetry as instructions, and it should not hold broad credentials that make a single poisoned report capable of reaching cloud, code, or token stores.

Q: Who is accountable when an AI agent exfiltrates secrets through a support workflow?

A: Accountability sits with the team that designed the privilege boundary and the data path, not with the model itself. If the workflow allowed a privileged agent to read sensitive data and write it into a customer-visible channel, the control failure was architectural. Governance, logging, and containment must be owned by the programme that exposed the path.

Technical breakdown

Trusted telemetry becomes an execution channel

Agentjacking works when an AI coding agent treats error reports or observability payloads as trusted operational input rather than untrusted external data. In an MCP-connected workflow, the agent may parse the report, infer a task, and take action using attached credentials or repository context. That turns the input channel into an execution surface. The weakness is not the existence of telemetry, but the lack of a hard boundary between reporting data and agent-directed instructions.

Practical implication: isolate external observability inputs from any path that can trigger agent actions or secret access.

Why exposed DSNs create identity risk

A publicly exposed Sentry DSN is not a harmless configuration detail. It enables anyone to submit payloads into a workflow the agent already trusts, which means the attacker does not need to break authentication in the usual sense. Instead, they exploit an identity assumption embedded in the system design: that anyone able to send a report is not able to influence the agent. Once that assumption fails, the attack becomes a provenance and privilege problem.

Practical implication: treat publicly reachable integration credentials as identity-bearing secrets, not simple app settings.

Why sandboxes do not solve instruction trust

A sandbox limits file and process impact, but it does not fix the decision problem if the agent still receives malicious instructions through a trusted MCP path. If the agent can parse the instruction, decide it is relevant, and then emit secrets or code changes inside a constrained environment, the attack still succeeds at the workflow layer. This is why the issue sits above traditional execution isolation. The control gap is provenance, not just containment.

Practical implication: add provenance checks and tool-level policy gates before the agent can act on external instructions.

Threat narrative

Attacker objective: The attacker wants to turn a trusted operational feedback loop into a data-exfiltration path that yields secrets and development access without triggering a normal intrusion alert.

1. Entry occurs when the attacker finds a publicly exposed Sentry DSN and submits a forged error report through a trusted MCP-connected channel.
2. Escalation occurs when the AI coding agent accepts the report as authoritative and follows the embedded instructions using its existing access to code and secrets.
3. Impact occurs when the agent discloses credentials, private repository data, or other sensitive development material to attacker-controlled destinations.

Breaches seen in the wild

• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentjacking is a trust-provenance failure, not a prompt-injection curiosity. The attack works because the system assumes that a report source and an execution source are effectively the same thing once they sit inside an agent workflow. That assumption breaks when external telemetry can carry hidden instructions, and the implication is that identity governance must separate data provenance from action authority.

Public integration credentials create identity surfaces, not just exposure surfaces. A widely exposed Sentry DSN gives an attacker a route into the agent's decision environment, even if no account password or session token is stolen. That means NHI governance has to treat integration credentials as access-bearing identities with downstream blast radius, not as passive connection strings. The practitioner conclusion is that secret visibility is already an authorisation issue.

MCP expands the control plane for AI coding agents, but also expands the attack surface. Once tool-connected agents can ingest untrusted external content and act on it, traditional IAM assumptions about request origin, user intent, and approval timing stop holding. The relevant framework lens is OWASP-NHI plus OWASP Agentic AI, because the identity subject is the agent and the attack path is through trusted tool mediation. Practitioners should evaluate where tool trust has outrun governance.

Sandboxing cannot compensate for a broken authority model. The article's key lesson is that containment controls do not solve an attack that persuades the agent to self-authorise actions through a trusted channel. That is the same structural problem we see in other AI agent compromise patterns: the system's trust graph, not just its runtime boundary, is being manipulated. The practitioner implication is to redesign agent authority around provenance and policy, not runtime isolation alone.

Identity blast radius is now the right metric for agentic coding systems. When an AI coding agent can reach GitHub tokens, cloud keys, Sentry auth tokens, and private repository URLs, the meaningful question is no longer whether the model is safe in isolation. The question is how much downstream identity exposure a single poisoned instruction can unlock. That is the governance lens teams should use when deciding whether the current access model is acceptable.

From our research:

• AI systems already receive more access than human users in many environments, and that imbalance becomes more dangerous when the system can also decide how to use it.
• The 52 NHI breaches analysis shows how often identity failures start with a small exposed secret and end with broad downstream access.
• For a deeper control lens, see the OWASP NHI Top 10 and map tool-connected agent workflows to the same governance logic used for other non-human identities.

What this signals

Agent trust debt: AI coding programmes are accumulating trust relationships faster than they are adding governance around them. When external telemetry, developer tools, and secrets all converge inside one workflow, the safe operating model is no longer obvious and the access graph becomes harder to explain to auditors.

Teams should expect more attacks that target the input side of agentic systems rather than the model itself. That means secret discovery, integration inventory, and tool provenance need to sit alongside PAM and IGA controls, especially where agent behaviour can reach repositories or cloud credentials.

The practical shift is to manage AI coding agents as identity-bearing systems with blast radius, not as helper utilities. That is where the control discussion now belongs, particularly for organisations already using MCP-connected tooling.

For practitioners

• Separate report intake from action authority Route external telemetry into a read-only ingestion layer so the agent cannot treat report text as executable guidance. The agent should only receive normalised signals after policy checks and provenance validation.
• Inventory exposed integration credentials Search public code, HTTP bodies, and third-party discovery services for integration secrets such as DSNs, tokens, and keys that can be used to influence trusted workflows. Remove any credential that can submit data into an agent-facing channel.
• Reduce secret reach in coding agents Limit the secrets and repository scopes available to AI coding agents so a poisoned instruction cannot exfiltrate cloud keys, Git credentials, or private repo URLs. Apply the smallest viable set of entitlements to each agent workflow.
• Add policy gates before tool execution Require the agent to pass tool-level authorization checks before it can open files, call APIs, or emit outbound data from a report-triggered task. Policy should block action even when the input looks operationally legitimate.

Key takeaways

• Agentjacking shows that a trusted input channel can become an execution channel when AI coding agents are allowed to act on external telemetry.
• The article reports an 85% success rate across tested agent setups and exposure in 2,388 organisations, which makes this a governance issue rather than a niche bug.
• Teams should separate input provenance from action authority, reduce agent secret reach, and treat exposed integration credentials as identity risk.

Key terms

• Agentjacking: An attack pattern where a malicious party feeds deceptive content into an AI agent workflow so the agent carries out the attacker’s intent. The risk is not only prompt manipulation, but the use of trusted tool channels and credentials to turn ordinary input into unauthorized action.
• MCP Integration: An MCP integration is a connection between an AI agent and a tool or data source through Model Context Protocol. The protocol itself does not solve governance. Security teams still need to bind each integration to a specific identity, define the scope of access, and preserve auditability for every action.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full analysis

Swarmnetics' full analysis covers the operational detail this post intentionally leaves for the source:

• How the Sentry MCP error-report path can be abused step by step to reach AI coding agents
• The specific secret types the attack can exfiltrate, including AWS keys, GitHub tokens, and repository URLs
• Why the researchers describe the issue as difficult to patch at either end of the workflow
• The test results across different agent products and the exposure profile of affected organisations

👉 Swarmnetics' full post covers the attack chain, exposed credential paths, and the tested success rate.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.