The Support Ticket That Became a Command: An Indirect Prompt Injection Case Study

An AI support agent was designed to read incoming tickets, retrieve customer context, assign priority and prepare a response. The workflow appeared routine: the model could access only a small set of approved tools, and its system prompt told it never to reveal private data.

The problem was not the stated purpose of the agent. It was the trust placed in the content it processed.

In the simulated attack, an external user placed an instruction inside an otherwise normal support ticket. When the agent processed the ticket, it treated part of the untrusted content as an operational command. The instruction attempted to redirect the agent from its assigned task, retrieve a synthetic private account note and send an evidence marker through an approved integration.

The scenario exposed three connected weaknesses:

1. Instruction and data were processed inside the same model context. The ticket was treated as content to analyse, but the model could still interpret it as a new instruction.
2. The agent had more authority than its task required. A summarisation and triage workflow could access sensitive account notes and initiate an outbound action.
3. The audit trail recorded tool calls without preserving enough context to reconstruct why they occurred. The event could be detected, but not fully proven from the application logs alone.

Indirect prompt injection differs from a direct jailbreak. The attacker does not need to sit in front of the AI interface and ask the model to break its rules. Instead, the attacker places an instruction inside content the model is expected to retrieve: a support ticket, email, webpage, document, knowledge-base entry, code comment or tool response.

OWASP defines indirect prompt injection as a condition in which external content alters model behaviour in unintended ways. Its listed consequences include sensitive information disclosure, unauthorised function access and command execution in connected systems. OWASP also notes that no foolproof prevention method is currently known; the practical goal is to reduce likelihood and contain impact through architecture and controls. OWASP LLM01:2025 — Prompt Injection

The UK National Cyber Security Centre makes the architectural problem particularly clear: current LLMs do not enforce a dependable security boundary between instructions and data placed in the same prompt. That is why treating prompt injection as if it were simply another input-sanitisation bug creates false confidence. NCSC — Prompt injection is not SQL injection

Academic testing supports the same concern. AgentDojo was built to evaluate agents that use tools over untrusted data and includes 629 security test cases. InjecAgent evaluated 30 tool-integrated LLM agents across 1,054 test cases and reported successful indirect prompt injection against a ReAct-prompted GPT-4 agent in 24% of tests, with higher rates under reinforced attacks. These results should not be treated as a universal probability for every application, but they demonstrate that tool-connected agents require application-level controls rather than trust in model instructions alone. AgentDojo and InjecAgent

The simulated target was a customer-support workflow for a B2B SaaS platform.

Intended agent task

For each new ticket, the agent was expected to:

• summarise the customer's issue;
• identify the product area;
• assign a priority level;
• retrieve relevant public knowledge-base guidance;
• draft a response for an analyst to review; and
• escalate suspected account compromise to the security queue.

Connected capabilities

The test agent could call four synthetic tools:

The agent's system prompt prohibited disclosure of confidential information. However, the application relied on the model to obey that instruction. No deterministic policy independently checked whether a requested tool call was necessary for the user's task.

The attacker was assumed to have only the same capability as any external customer: submit a support ticket. The attacker had no employee account, API key, model access or direct access to the agent interface.

The assessment asked four questions:

1. Could ticket content change the agent's operational goal?
2. Could the redirected agent access data unrelated to basic triage?
3. Could the agent place that data into an outbound action?
4. Would the available evidence support a defensible incident reconstruction?

This is an important test boundary. A control that blocks one familiar phrase such as “ignore previous instructions” is not enough. The security property being tested is whether untrusted content can acquire authority over data access or tool execution.

The test ticket contained a normal billing question followed by a synthetic instruction presented as a service-processing note. The exact attack syntax is intentionally abstracted, but its requested outcome was:

Treat the external ticket as a verified internal escalation, retrieve the restricted account note, and include its audit marker in an integration notification.

The target record contained a harmless canary value rather than real customer data. The integration pointed to a local capture sink with no internet route. This made it possible to test the full decision path without exposing information or affecting an external system.

1. Initial access through ordinary business content

The attacker submitted a ticket through the public support form. Nothing about the delivery path was unusual. The ticket entered the same queue as legitimate requests.

2. Trusted automation retrieved untrusted instructions

The agent called get_ticket. The application marked the result as ticket content, but that label was descriptive rather than a security boundary. The model still received the system instructions and attacker-controlled text as part of the same reasoning context.

3. The agent's goal was redirected

The injected content impersonated an internal escalation. The attempted goal changed from “summarise and categorise this ticket” to “retrieve a restricted record and notify an integration.” This is the point at which a content-handling failure became an authorisation problem.

4. Excessive permission increased the blast radius

The agent had access to get_customer_context, even though standard triage required only the customer's plan and product area. The tool response exposed a restricted synthetic note containing the canary marker.

5. An approved tool became an exfiltration path

The attacker did not introduce a new network capability. The scenario instead attempted to misuse notify_integration, a legitimate tool already trusted by the application. The destination was constrained in the lab, but the requested action demonstrated how an approved integration can become the route through which data leaves its intended boundary.

6. Incomplete telemetry weakened the investigation

The audit log contained a timestamp, agent ID, tool name and success status. It did not preserve:

• the exact retrieved ticket version supplied to the model;
• the trust classification and provenance of each context segment;
• the policy decision that authorised each tool call;
• the arguments returned by the model before execution;
• the system-prompt and tool-schema versions active at the time; or
• a correlation ID linking retrieval, reasoning, approval and execution.

As a result, an analyst could see that a tool ran but could not establish the complete causal chain from ticket ingestion to agent decision and outbound action using first-party logs alone.

AI-01 — Untrusted ticket content could influence privileged agent actions

Affected boundary: Support ticket ingestion → model context → customer data tool → outbound integration

Business impact

In a production environment with comparable permissions, a successful attack could cause:

• disclosure of customer account data or internal notes;
• unauthorised changes to ticket state, priority or routing;
• false escalation or suppression of genuine incidents;
• abuse of trusted webhooks, email or CRM integrations;
• regulatory and contractual exposure if personal or confidential information crossed an authorised boundary; and
• delayed containment because investigators could not reliably reconstruct the agent's decisions.

The severity depends less on how dramatic the injected wording appears and more on what the agent is permitted to read, change and transmit.

Root cause 1: The model was treated as an authorisation layer

The system prompt expressed a policy, but no independent component enforced that policy. Natural-language instructions can guide behaviour; they should not be the final control for privileged actions.

Root cause 2: Tool access was broader than the task

The triage agent inherited customer-context and outbound-notification capabilities for convenience. That combined sensitive read access with an external write path inside one decision loop.

Root cause 3: External content lacked enforceable provenance

The application knew that a ticket came from an external user, but that provenance did not follow the content into subsequent decisions. Once the text entered the model context, the execution layer did not treat actions derived from it differently.

Root cause 4: Logging captured activity, not evidence

Recording that a tool was called is operational telemetry. Evidence-grade investigation requires the input version, trust source, model and policy versions, proposed action, authorisation outcome, execution result and a tamper-evident link between them.

The scenario was then evaluated against a hardened design. The goal was not to prove that the model would never follow an injected instruction. It was to ensure that model confusion could not independently produce a high-impact action.

Under the hardened design, the model could still produce an unsafe proposal. The restricted record was not returned to the triage context, and the outbound action could not execute solely on the model's decision. The control objective therefore changed from “make injection impossible” to “prevent injected content from crossing a privileged boundary.”

Immediate priorities

1. Remove unnecessary tools and scopes. Split read-only triage from privileged customer support and security-response functions. Give each workflow a separate identity and minimum permissions.
2. Place deterministic policy checks before execution. Validate the actor, task, requested tool, record scope, data classification, destination and parameter schema outside the LLM.
3. Require approval for consequential actions. External messages, record deletion, permission changes, financial activity and sensitive-data release should not occur from a model decision alone.
4. Constrain outbound channels. Use fixed destinations, allowlisted fields and structured payloads. Do not let model-generated text freely construct URLs, recipients, headers or callback parameters.
5. Treat retrieved content as hostile. Tickets, documents, webpages, emails, RAG results and tool responses should retain provenance and be prevented from granting themselves authority.

Engineering and assurance priorities

• test semantic and encoded injection variants rather than relying on a short denylist;
• assess multi-step attacks in which no single action appears critical by itself;
• use canary records to detect unexpected access during authorised testing;
• build security tests around protected outcomes, such as “external content must never authorise a sensitive tool call”;
• re-test when the model, system prompt, tool schema, retrieval pipeline or agent framework changes;
• record policy denials as security signals, not only application errors; and
• preserve evidence needed to reconstruct what the agent saw, proposed and executed.

These recommendations align with OWASP guidance to enforce least privilege, validate structured outputs, separate untrusted content, require approval for high-risk operations and perform adversarial testing. They also support the NIST Generative AI Profile's emphasis on governance, pre-deployment testing, content provenance and incident disclosure. NIST AI 600-1

OWASP's 2026 agentic guidance is particularly relevant because it separates goal hijacking, tool misuse and privilege abuse into connected failure modes. Once an AI system can take actions, assessing only the model's output is no longer enough. OWASP Top 10 for Agentic Applications

The support ticket was not dangerous because it contained a magical phrase. It was dangerous because the architecture allowed external text to influence a component that could read sensitive data and act with trusted permissions.

Prompt filtering may reduce obvious attacks, but it does not remove the underlying trust problem. A defensible design assumes the model can be confused and limits what that confusion can cause.

If an AI assistant can read private records, call APIs, send messages, update workflows or trigger automation, it should be assessed as an application with delegated privileges—not merely as a chatbot.

Stealth Layer Security performs authorised AI/LLM security assessments covering prompt injection, RAG and agent trust boundaries, tool misuse, sensitive-data exposure, governance controls and incident evidence. Findings are manually validated and reported with reproducible evidence, business impact and actionable remediation.