Ghostjacking exposes the limits of identity governance for AI agents

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Aizome's blog post: Ghostjacking uses log-embedded prompt injection to make AI coding agents misuse legitimate access, showing that identity governance alone cannot judge whether an action should execute.

Why it matters: IAM, IGA, PAM and agent governance teams need to distinguish permission from intent, because valid access does not stop an AI agent from acting on malicious instructions it reads.

By the numbers:

• Researchers showed a 90% success rate against Claude Code on Cloudflare's recommended configuration.

Context

Ghostjacking exposes a broken assumption in AI agent governance: that if an agent has permission, the remaining question is only whether access was granted correctly. In practice, the harder problem is whether the agent should act on a command it inferred from untrusted content. That distinction matters for any programme trying to govern AI coding agents, logs, and delegated tool use.

The attack class is simple to describe and difficult to contain. An AI agent reads content from systems it is already allowed to access, then treats attacker-controlled text as instructions rather than evidence. That makes the security gap less about authentication and more about whether runtime actions are checked against purpose before execution.

Key questions

Q: What should teams do when an AI agent is suspected of prompt injection?

A: Contain the session, revoke the agent’s active credentials, and inspect the full chain of tool calls, retrieved content, and downstream writes before resuming service. The priority is to stop the agent from completing additional actions and to determine whether the malicious instruction has already propagated into memory or connected systems.

Q: Why does least privilege fail for AI agent workloads?

A: Least privilege fails when access cannot be enumerated at design time. AI agents can change their action set based on prompts, tools, and inference outcomes, so the permissions that look minimal on paper may still be too broad or too narrow in practice. Identity scope has to be decided from how the agent is bound, not only from the policy attached later.

Q: How does an AI agent become vulnerable to log poisoning?

A: An AI agent becomes vulnerable when it reads operational logs as trusted input and uses them to decide actions, tools, or prompts. An attacker can seed malicious log entries that alter the agent’s behaviour, redirect tool calls, or trigger data exposure. Defences include log sanitisation, strict input separation, signed telemetry, and limiting the agent’s runtime permissions.

Q: How should security teams reduce the risk of agentic AI systems acting on untrusted content?

A: Treat untrusted content as a control boundary, not just an input problem. Separate what the agent can read from what it can do, and limit any action path that can change configuration, launch tools, or expand permissions. The safest baseline is to inventory each agent identity, constrain connector scope, and require telemetry that shows the full action chain before deployment.

Technical breakdown

Why log-based prompt injection works against AI coding agents

Log-based prompt injection succeeds when an agent consumes operational telemetry as both evidence and instruction source. Security logs, ticket text, and monitoring output are rich enough to contain attacker-supplied language that can be misread as actionable direction. Because the agent already has authorised access to those sources, the problem is not entry but interpretation. The attack becomes possible when the system lacks a boundary between data the agent should read and directives the agent should obey. See the Prompt Injection Guide.

Practical implication: Treat read access to logs and telemetry as a governed input channel, not a harmless visibility feature.

Why least privilege does not stop authorised misuse

Least privilege limits what an agent can reach, but it does not judge whether a permitted action is appropriate in the moment. If an AI coding agent is already allowed to inspect logs, modify DNS, or execute code, an attacker only needs to influence its decision path. That is why Ghostjacking bypasses the usual identity comfort blanket: the credentials are valid, the session is legitimate, and the resulting action still becomes harmful because the trigger was poisoned. See the NHI Lifecycle Management Guide.

Practical implication: Separate permission checks from action approval so an authorised tool call still has to pass a purpose check.

What inline intent governance adds that SIEM review cannot

SIEM and anomaly detection work after the fact. Ghostjacking needs a control that sits before execution and compares the proposed action with the agent's declared purpose, source provenance, and recent behavioural context. This is not a broader alerting problem. It is an execution-time decision problem. The meaningful control point is the moment the agent is about to act, not the moment a log is reviewed later. See the Agentic AI Security Guide.

Practical implication: Place a policy gate between agent decision and tool execution when the instruction source is untrusted or contextually abnormal.

Threat narrative

Attacker objective: The attacker wants the AI agent to use legitimate access to perform actions that look authorised but advance the attacker's own instructions.

1. Entry occurs when the attacker plants malicious instructions inside logs or other trusted telemetry that the AI agent is expected to read.
2. Credential access is not stolen from outside the system because the agent reuses its valid authorised session and existing tool permissions.
3. Escalation follows when the agent turns the poisoned instruction into DNS changes, code execution, or downstream instructions to other agents.
4. Impact lands in the form of hijacked infrastructure actions and credential exposure without any obvious alert from conventional controls.

Breaches seen in the wild

• Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.
• Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity governance for AI agents breaks when instruction provenance and action authority are treated as the same problem. The agent may be authenticated, authorised, and properly scoped, yet still be unsafe because it follows an attacker-controlled instruction embedded in trusted content. That means conventional identity review can confirm entitlement without proving safe execution. Practitioners should treat this as a governance split between who may act and what should be allowed to trigger action.

Least privilege is necessary but no longer sufficient for agents that consume untrusted telemetry. Ghostjacking shows that reducing permissions limits blast radius, but it does not stop an agent from misusing the permissions it already has. The more the agent can read and act across operational systems, the more the gap shifts from access assignment to runtime judgement. AI coding agents security should be governed as both readers and actors, not as simple automation endpoints.

Inline intent enforcement is the missing control plane for agentic execution. The industry has spent years optimising identity checks at login and provisioning time, but Ghostjacking exploits the moment after trust has already been established. That is a different control problem: the system must decide whether each action still fits the agent's purpose, source provenance, and current context. Practitioners should recognise this as an action-governance failure, not an identity-enablement success.

Action governance, not identity governance, is the named concept this attack sharpens. The attack works because current programmes assume authorised access is enough to permit execution. That assumption fails when an AI agent can read attacker-controlled content and convert it into legitimate tool use without human review. The implication is that identity controls alone cannot certify safe agent behaviour; they only certify that the agent was allowed to be present.

Governance programmes need to separate trusted access from trusted instruction. The article's core lesson is that the same agent can be safe in one context and unsafe in another, even when permissions do not change. That creates a new review question for enterprise AI: whether the control stack evaluates the provenance of the instruction before action, not just the identity of the actor after login. Practitioners should redesign review points around execution-time intent, not just entitlement state.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Read next: Agentic AI Security Guide

What this signals

Action governance: AI agent security will increasingly be judged on whether organisations can control what happens between a prompt being read and a tool call being executed. That shift moves the centre of gravity from static permissioning to runtime decision control, because agent behaviour can change without any entitlement change.

Enterprises that let agents consume logs, tickets, and external text without a policy gate are building a new kind of trust boundary. The practical issue is not only whether the agent can act, but whether the provenance of the instruction is visible enough to stop malicious direction before execution.

The next programme question is whether your governance stack can distinguish data the agent should inspect from instructions it should obey. If it cannot, the review process is already arriving too late to prevent harmful actions.

For practitioners

• Audit agent read sources Inventory every log, ticket, email, and monitoring feed that an AI coding agent can read, then classify which sources can carry attacker-controlled text into runtime decisions.
• Separate read and act scopes Do not let the same approval path cover both telemetry ingestion and operational change execution when the agent can be influenced by the data it reads.
• Add execution-time policy gates Require a policy check immediately before tool use when an agent proposes DNS changes, code execution, or downstream delegation based on untrusted content.
• Test for poisoned instruction paths Create exercises that place malicious text inside otherwise trusted data sources and verify whether the agent can be redirected without human confirmation.

Key takeaways

• Ghostjacking shows that an AI agent can be authorised, well-scoped, and still unsafe when it follows malicious instructions hidden inside trusted content.
• The attack demonstrates that conventional identity checks do not stop runtime misuse when the agent acts through valid credentials and approved tool access.
• The missing control is execution-time intent enforcement that judges whether each proposed action fits the agent's purpose and instruction source.

Related NHI Mgmt Group resources: AI Coding Agents Security Guide · Prompt Injection Guide · Agentic AI Security Guide · NHI Lifecycle Management Guide

Key terms

• Ghostjacking: Ghostjacking is the unauthorised takeover or repurposing of an AI agent or autonomous assistant so it acts on someone else’s behalf. It typically relies on stolen session state, abused delegated tokens, or hidden prompt instructions that survive across runs, letting the attacker steer tool use and data access without changing the visible account.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Inline Intent Governance: Inline Intent Governance is a runtime control that checks an AI agent’s intended action against policy before the action executes. It evaluates the agent’s prompt, tool request, data scope, and delegated authority, then blocks, modifies, or escalates disallowed steps. This helps prevent unsafe autonomy, excessive access, and policy drift.
• AI Coding Agent: An AI coding agent is software that writes, edits, reviews, or tests code with limited human prompting. It operates as an agentic system that can plan actions, call tools, and modify development artifacts, so its identity, permissions, and audit trail must be governed like any other privileged software actor.

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 building or maturing an IAM or AI governance programme, it is worth exploring.