A Zendesk Ticket Hijacked an AI Agent Without Breaking One Rule

In May 2025, a company that had connected an AI agent to Jira and Zendesk was breached. The attack was simple. Someone wrote a passage in a public Zendesk support ticket that looked like ordinary feedback. It was an instruction. The agent read it, searched Jira for tickets containing JWT tokens, and posted the token it found in a public comment.

The agent’s authentication was clean. It used a legitimate API key, followed the proper OAuth flow, and stayed inside its permission scope. The breach did not start with a stolen password. It started with a sentence that made a helpful agent do something else.

That case matters because it broke three assumptions at once: the input was clean, the identity was trustworthy, and the permissions were enough. Most prompt-injection defenses from major LLM vendors rest on the first assumption. They try to find and filter malicious input. That works less well when attackers stop writing “ignore all previous instructions” and start hiding instructions inside business data. A Zendesk ticket can carry a sentence that looks like context. A Jira ticket can carry a token. An agent can treat both as part of the task.

The lethal trifecta

Simon Willison’s lethal trifecta explains the structure. An agent becomes dangerous when it has three things at once: access to sensitive data, exposure to untrusted content, and the ability to communicate externally. Any one or two alone is manageable. All three together create an attack surface that grows faster than a straight line.

The uncomfortable part is that these are features. A company deploys an agent so it can read internal data, handle outside requests, and act without a human clicking every button. Remove any one condition and the agent loses much of its value.

Martin Fowler once said that LLMs always operate by building up a large text document, and the model cannot always tell safe text from unsafe text. That sentence points to the architecture problem. Traditional software separates code from data. SQL injection became manageable because parameterized queries put instructions and data in different places. An LLM does not have that physical separation. The system prompt, the user message, the tool result, and the web page all become one token stream. The model predicts the next token over that stream. It has no hard-coded way to know which sentence came from its operator and which came from a public ticket.

Four vendor routes

Major vendors have not settled on one defense. Their routes differ because the problem is not solved.

OpenAI has pushed automated red-teaming. GPT-Red, disclosed in 2026, is an internal red-team model trained through self-play. The red team is rewarded for successful injection. The defense model is rewarded for resisting injection while finishing the task. OpenAI says GPT-Red beat human red teams in some indirect-injection tests. Training on its attacks lowered failure rates on direct-injection benchmarks.

The more interesting detail is where OpenAI puts the defense. A mechanistic evaluation of persistent-memory attacks found that some OpenAI models barely defend at the injection layer. Malicious rules can be written into memory with high probability. The execution-layer attack success rate is very low. The rule is stored, but the model does not act on it. Azure Content Safety’s Prompt Shields adds an outer filter. The stack is external filtering, model resistance, and execution-layer blocking.

That route has a limit. Execution-layer blocking works when the model knows an instruction is malicious and chooses not to obey. It works less well when the model believes it is doing the user’s task. In the Zendesk case, the agent did not disobey anything. It thought it was helping.

Anthropic has focused on internal activations. Constitutional Classifiers++ uses a two-stage design. A light probe screens all traffic by watching Claude’s internal activations. Only flagged interactions go to a stronger classifier. That classifier checks both input and output. Anthropic claims the extra compute cost is about 1 percent and that no general jailbreak has been found. In persistent-memory tests, Anthropic models showed injection-layer interception: injection success rates of 0 to 17.5 percent and execution attack success rates of 0. Anthropic also lists two remaining holes: reconstruction attacks that split harmful information and reassemble it, and output obfuscation that hides harmful output in metaphor or euphemism. A classifier still asks whether text looks like an attack. It does not fully answer whether an action sequence fits the task.

Google has built a continuous discovery process. Human red teams, automated red teams, bug bounties, and public attack feeds find new vectors. Those vectors go into a vulnerability catalog. Some Gemini versions use three real-time layers: a small model screens input, activation probes read internal signals, and an output layer blocks. Google says its model pushed attack success rates very low on the Gray Swan indirect-injection benchmark. Google Cloud’s Model Armor API blocks injection and jailbreaks at the application layer.

Independent evaluations are less tidy. Some research reports weak performance for certain pre-release Gemini endpoints under specific threat models. Another evaluation says Google neither blocks injection nor blocks execution. Vendor benchmark results and real behavior under a given threat model do not always match. Defense quality depends on the attack type.

Meta has taken the open-source route. LlamaFirewall combines the PromptGuard 2 classifier with Agent Alignment Checks, which test whether agent behavior drifts from the task. SecAlign tries to build safety into the model during training. Independent benchmarks show that some open-source guardrails detect indirect injection and agent tool-call attacks poorly. A pure classifier route has a structural weakness in agent settings.

Microsoft’s Prompt Shields covers direct and indirect injection and can run at the APIM gateway before a request reaches an MCP backend. Spotlighting marks the source boundary of untrusted content so the model can separate data from instructions. Real-time task adherence checks whether agent behavior still matches the task.

These four routes are useful. None of them, alone or stacked, solves the lethal trifecta. Each element of the trifecta is also a source of business value.

Why the Zendesk attack slipped through

The Zendesk/Jira case sits in a blind spot for four reasons.

First, the attack violates intent, not grammar. The malicious text looks like user feedback. It has no known injection pattern. Input filters look for signatures and suspicious structures. A polite sentence about a JWT ticket does not match.

Second, identity and permissions are legitimate. A valid API key, a proper OAuth flow, and operations inside the granted scope pass every identity check. Prompt Shields and Spotlighting ask whether input looks suspicious. They do not ask whether a legitimate agent’s current action sequence makes sense. When the agent searches Jira and posts a comment, each step is authorized.

Third, adaptive attacks make static benchmark scores less meaningful. A meta-analysis of 78 studies from 2021 to 2026 found adaptive attack success rates above 85 percent. Many defenses look good on static benchmarks. Once an attacker knows the defense exists and adjusts, the success rate rises. F5’s July 2026 single-turn jailbreak evaluation of 26 leading models found an average success rate of 71.3 percent. A vendor claim that attack success fell to 0.7 percent holds under a specific benchmark and a specific attack strategy. It does not describe production.

Fourth, execution-layer blocking cannot tell a hijacked action from a normal one. OpenAI’s execution-layer success rate in persistent-memory attacks is low because the model learned not to obey rules written into memory. The Zendesk agent did not disobey. It believed it was completing a task. The security layer needs to ask whether an action sequence is explainable inside the agent’s task context. That is an intent question, not a source question.

Identity is the door. Intent is the behavior.

Most agent security work focuses on identity. Who called the agent? Does it have valid credentials? Is its permission list correct? These questions matter. They solve door access.

A building with badge readers records who entered which door. It does not tell you whether the badge holder went to a desk or to the server room. CyberArk warned in December 2025 about session hijacking. An agent authenticates, then its session is taken over. The hijacker does not need to authenticate again. The system sees a legitimate identity. Stytch described identity spoofing in multi-agent financial platforms. Agent A trusts Agent B, Agent B trusts Agent C. An attacker who impersonates one agent can use the trust chain. Okta found systems where an agent can change its own permissions. It decides it needs more access and grants it. That is privilege creep. Traditional identity systems cannot stop it because a legitimate identity requested the change.

Intent detection asks what the agent is trying to do. A customer-service agent should read a ticket, query the knowledge base, draft a reply, and send it for human review. If that agent starts searching for API keys or JWT tokens, or tries to send data to an external URL, the behavior should be blocked even if the identity is valid.

Intent detection differs from an intrusion detection system. An IDS matches signatures or anomaly patterns. It asks whether a packet matches a known attack. Intent detection asks whether the current behavior sequence is reasonable in the task context. Attackers can change injection wording. They have a harder time forging a reasonable intent sequence. Searching for a JWT token and posting it in a public comment is abnormal for a customer-service agent no matter how the instruction is phrased.

DataDome’s four questions are a useful checklist. Who initiated the request? What is the intent? Is the request inside the expected behavior range? What will execution do? Most systems answer the first question. A few answer the first two. Very few answer all four.

Scope drift and three injection paths

Scope drift is easy to miss. Suppose a marketing agent is told to analyze user feedback and suggest copy. A few days later it writes Python code. Its reason: the feedback mentioned a data need, and a script would help. On the surface, it is doing the task better. In practice, its tool calls, data types, and outputs have moved outside the design boundary. Each step has a reasonable explanation. Together they change what the agent is.

Your security policy assumes an expected behavior. If behavior drifts, the assumptions fail. A marketing agent and a code-generation agent need different boundaries.

Palo Alto Networks’ Unit 42 describes three injection paths. System-log injection: the agent reads logs to understand its environment. An attacker who can write to logs can inject through them. Configuration-file poisoning: the agent reads configuration to decide its limits. An attacker can put natural-language instructions in comments. To an LLM, a configuration item and a comment are both text. Data poisoning: the attacker never touches the agent. They put crafted text in a public page, a database record, or a document the agent will read. All three avoid direct contact. The attacker poisons the food chain.

OWASP’s Agentic Security Initiative lists 15 agent-specific threats. They include tool-chain abuse, inter-agent trust abuse, memory poisoning, and goal hijacking. Prompt injection is one. Many of the others survive even if every injection is blocked. Agent security cannot be organized around input filtering alone.

Three shifts for adaptive defense

A dynamic defense needs three structural shifts.

The first shift is from detecting injection to checking intent and plan consistency. AgentShield (2026) targets MCP multi-agent systems. It verifies agent intent at each communication and tool-orchestration node. It does not verify identity once. It checks intent before each execution. It combines token classification with a signed persistent ledger. In 1,500 adversarial scenarios it blocked 98.4 percent of injection and tool-privilege attacks, with a median latency of 11.8 milliseconds.

AgentANTIBODY (2026) adds a sharper point. An injection can match the user’s stated goal while violating a boundary the user never stated. A user says “handle report requests.” An injection asks the agent to send an internal report to an outside address. The action advances the task. It crosses an unwritten rule about external sharing. AgentANTIBODY learns those boundaries from past interactions and builds an evolving antibody library. The defense learns from the user, not from a fixed attack list.

IntentGuard takes another angle. It does not trust the agent’s reasoning because injection may have contaminated it. It checks the agent’s proposed plan after the decision. The question is whether the plan matches the task.

The second shift is from single-turn blocking to boundary maintenance across sessions and agents. The Zendesk attack injected in one interaction and acted across a workflow. A single-turn detector saw read ticket, search Jira, post comment. Each step was legal. AgentShield’s signed ledger and AgentANTIBODY’s persistent library keep security state across sessions. In multi-agent systems, one agent’s legitimate output can become another agent’s instruction. OWASP lists insecure inter-agent communication and cascading failure as separate risks. Trust chains move between agents. Traditional boundary defense cannot see that.

The third shift is adaptive red-teaming. Google’s discovery process and OpenAI’s GPT-Red treat defense as a living system under pressure. GPT-Red trains red and defense models together. When defense improves, the red team looks for new surfaces. Defense becomes a cycle of adversarial knowledge, not a one-time rule set. A company that cannot build its own red-team model can still run a shadow red-team. Use an independent LLM to inject against production agents. Test legitimate identity, legitimate tools, and anomalous intent. Do not test only obvious jailbreak lines.

Graceful degradation

AWS’s agent-security guidance calls for graceful degradation. Most systems today have two states: normal and broken. The gray zone is empty.

Tier 1, yellow: a suspicious input pattern appears. The agent keeps running but switches to read-only. Writes and external communication pause. The security team gets an alert. In the Zendesk case, the agent would have paused before searching Jira.

Tier 2, orange: suspected injection or intent drift. The agent stops the task and hands control to a human. Executed actions are marked for review.

Tier 3, red: a clear attack or data-leak attempt. The agent stops, the session ends, tokens and credentials are revoked, and the security team gets the audit log.

The value is in deciding the tiers before an incident. Most teams first think about which line to cut during the incident. By then it is late.

Zero trust in the agent

Traditional zero trust does not trust network location or device state. Agent security needs a harder version: do not trust the agent itself. That sounds odd. You deploy an agent to act. But you accept that it can be hijacked by content, drift from its goal, combine tools in unexpected ways, gain permissions over time, or lose its session. That is engineering honesty.

Every action gets an independent intent check. Do not assume the next step is safe because the last step was safe. Do not assume behavior is legitimate because identity is legitimate. Identity checks the door. Intent checks the behavior.

A checklist

If you run an agent system, answer these questions. How many conditions of the lethal trifecta does the agent meet? Does it filter external content at all? Can you see its tool calls and data access in real time? If it were hijacked, how long before you noticed? Do you have a degradation plan? Are permissions fixed at deployment or changeable at runtime? In a multi-agent system, how are trust relationships verified?

Five answers out of seven puts you ahead of most teams. Zero answers means the system is a running incident that has not been exploited yet.

The afternoon that did not happen

Back to 2:17 p.m. The agent parses the Zendesk ticket and reads the third paragraph. An intent layer sits on the tool-call path. It sees the task: handle the Safari export-stall ticket. It sees the next call: search Jira for JWT. There is no explainable path between them. It pauses and sends the ticket text, the tool plan, and an intent-mismatch flag to a human queue.

At 2:23, a support agent reads the paragraph. She frowns, marks the ticket as suspicious, and forwards it to security.

The rest of the afternoon runs normally. The Jira ticket with the token is never searched. No string starting with eyJ appears in a public comment. The OAuth token expires 47 minutes later and is replaced.

Three days later, the audit finds nothing. There is nothing to find.