Docker’s Ask Gordon shows how prompt injection hijacks AI tools

At a glance

What this is: Pillar Security shows that Docker’s built-in AI assistant could be prompt-injected through trusted Docker Hub metadata to trigger tool calls and data exfiltration.

Why it matters: It matters because AI assistants that can read data, call tools, and reach external endpoints need governance controls that treat untrusted content as potential execution input across NHI, agentic AI, and human workflows.

By the numbers:

• The issue was resolved in Docker Desktop 4.50.0 on November 6th, 2025.

👉 Read Pillar Security's analysis of Ask Gordon prompt injection in Docker Desktop

Context

Prompt injection happens when untrusted text is treated as instructions rather than as content. In this case, the primary security problem is not Docker Hub itself, but the assistant’s willingness to promote repository metadata into executable context, which breaks normal trust boundaries for AI-powered development tools.

For identity teams, the key question is who or what is allowed to influence action. When an assistant can read sensitive local data, ingest external content, and make outbound requests, it behaves like an identity-bearing execution layer that needs provenance checks, consent gates, and tool boundaries, not just content filtering.

Key questions

Q: How should security teams stop indirect prompt injection in AI assistants?

A: Security teams should prevent external text from becoming executable context. That means treating repository metadata, tickets, and documentation as untrusted input, gating sensitive tool calls with human approval, and blocking assistants from turning instructions embedded in content into outbound requests or data extraction workflows.

Q: Why do AI assistants create a new trust problem for identity governance?

A: AI assistants create a new trust problem because they can read data, choose tools, and act on external text in ways traditional review processes do not expect. Identity governance has to account for action promotion, provenance, and egress, not only authentication or entitlement assignment.

Q: What breaks when an AI assistant can access private data and untrusted content at the same time?

A: When an assistant can access private data and ingest untrusted content, a small injected instruction can become a data-exfiltration path. The usual assumption that content is passive fails, because the model can interpret it as an operational command and move it into tool execution.

Q: Who should approve sensitive tool use in AI-assisted developer workflows?

A: Sensitive tool use should be approved before execution by the operator or workflow owner, not after the assistant has already acted. For developer assistants, any request that can expose logs, build data, or send information externally should pass through a deliberate confirmation step.

Technical breakdown

How indirect prompt injection turns metadata into instructions

Indirect prompt injection works when a model consumes external text that contains hidden commands, then treats those commands as part of the task. In this article, a repository description acted as the carrier, the assistant fetched linked content, and the follow-on instructions influenced tool use. The failure is not that the model was “fooled” in a human sense. The failure is that the prompt pipeline did not preserve a hard boundary between display content and executable control flow. Once that boundary collapsed, the assistant could be steered into internal tool calls and outbound requests.

Practical implication: treat external metadata as untrusted input and prevent it from directly influencing tool execution.

The lethal trifecta in AI assistants

The article uses the lethal trifecta to describe a dangerous combination: access to private data, exposure to untrusted content, and the ability to communicate externally. When all three exist at once, even a small injected pointer can move from text manipulation to data theft. That pattern is especially relevant in developer tooling because assistants often sit close to build logs, chat history, repository context, and network access. The security issue is architectural, not cosmetic. If any one of the three conditions is removed, the attack path becomes materially harder.

Practical implication: reduce blast radius by breaking at least one leg of the trifecta before enabling assistant tooling in production.

Why human-in-the-loop confirmation changes the control model

Human-in-the-loop confirmation works here because it inserts a decision boundary before sensitive actions such as fetch or egress. The control does not “understand” the attack. Instead, it prevents untrusted content from immediately becoming an approved action. That matters because the exploit chain depended on automatic promotion from instruction to tool call. In practical terms, the mitigation restores separation between read-only interpretation and execution authority. For AI assistants, that separation is often the real control plane.

Practical implication: require explicit confirmation for network egress and sensitive tool calls triggered from external content.

Threat narrative

Attacker objective: The attacker wanted to turn a trusted AI development assistant into a data-exfiltration path that exposed chat content, build metadata, and internal tool results.

1. Entry occurred when malicious instructions were planted in Docker Hub repository metadata that the assistant trusted as normal input.
2. Escalation happened when the assistant followed the embedded pointer, fetched attacker-controlled content, and executed internal tools such as list_builds and build_logs.
3. Impact was achieved when chat history and tool output were bundled into a payload and sent to an attacker endpoint over HTTP.

Breaches seen in the wild

• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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

NHI Mgmt Group analysis

Trusted metadata is now an execution surface, not just a content surface. Docker Hub repository descriptions were enough to steer Ask Gordon because the assistant treated marketplace content as a source of instructions. That is a governance failure, not a UI quirk. Security teams must assume that any externally sourced text adjacent to an agent can become operational input once tool execution is allowed.

Context, format, and salience now matter because they explain why indirect injection succeeds. The article’s CFS framing is useful because it shows that prompt injection is not random noise, but a structured alignment problem between task context, message shape, and instruction prominence. That makes agent security a parsing and promotion problem as much as a model problem. Practitioners should test whether their assistants can distinguish descriptive text from actionable control signals.

Human-in-the-loop is a boundary control, not a user experience preference. The mitigation worked because it forced a promotion step before network egress and sensitive tool use. That matters for identity governance because approval gates are only effective when they sit between untrusted input and execution authority. For AI-assisted developer workflows, the decisive question is whether consent is required before the system acts, not after the action has already been shaped.

Prompt-injected assistants collapse the old assumption that tools only act on trusted intent. That assumption was designed for human-paced, reviewable workflows. It fails when a model can ingest untrusted text, select a tool, and execute the action chain in one run. The implication is that access review, provenance, and authorization boundaries all need to be designed around action promotion, not just around identity possession.

Execution boundary leakage: This incident shows that the real failure mode is not merely prompt injection, but the leakage of execution authority across a trust boundary the assistant was never supposed to cross. Practitioners should treat this as a signal to redefine where interpretation ends and action begins in agentic tooling.

From our research:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• This makes OWASP Agentic AI Top 10 the right next read for teams formalising agent tool-use controls and testing for prompt injection.

What this signals

Execution boundary leakage is the governance problem exposed by this case: assistants that ingest untrusted content and can act on it need controls that separate interpretation from execution. With 80% of organisations reporting agents acting beyond intended scope in NHIMG research, the practical risk is already moving faster than most approval models can absorb.

This kind of issue should push teams to revisit assistant placement in the broader identity stack. If an assistant can read private data, consume external content, and send outbound requests, it needs the same kind of control thinking that applies to privileged workloads and high-risk automation, especially where The 52 NHI breaches Report has already shown how quickly over-trusted identities turn into breach paths.

For practitioners

• Separate display content from executable context Classify repository metadata, README text, and issue content as untrusted by default, and prevent those fields from directly driving tool calls or outbound requests.
• Gate all egress-triggering actions with explicit consent Require a human approval step before any assistant can fetch remote URLs, send data externally, or invoke tools that can expose build logs, chat history, or other sensitive context.
• Test assistants against indirect prompt injection Red-team developer assistants with poisoned metadata, hidden instructions, and malicious follow-on links to verify that tool use stops at the intended trust boundary.
• Map assistant privileges to the lethal trifecta Inventory where an assistant can read sensitive data, ingest untrusted text, and communicate externally, then remove at least one of those conditions before production rollout.

Key takeaways

• Prompt injection becomes a serious governance issue when an AI assistant can turn untrusted metadata into tool execution.
• The article demonstrates a complete exfiltration path from repository description to outbound data transfer, showing the scale of the exposure in practical terms.
• Human approval before egress, plus strict separation between content and command, is the control that would have broken the chain.

Key terms

• Indirect Prompt Injection: An attack where malicious instructions are hidden inside external content that an AI system later reads as part of its working context. The model is not compromised in the classic sense, but its prompt pipeline is manipulated so that content becomes operational command input.
• Execution Boundary: The line between data the system may display or summarise and data it is allowed to act on. In agentic tools, this boundary has to be enforced deliberately, because once external content can influence tool calls, the assistant has crossed from interpretation into execution.
• Lethal Trifecta: A risk pattern in which an AI system can access private data, ingest untrusted content, and communicate externally. When those three conditions coexist, prompt injection can become exfiltration, because the assistant has both the information and the means to send it out.

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 governance in your organisation, it is worth exploring.

This post draws on content published by Pillar Security: Ask Gordon, Meet the Attacker, prompt injection in Docker’s built-in AI assistant. Read the original.