AI Agent Hijacking: How to Test Email, Web and Code Workflows

AI agents are being asked to read the same untrusted material that attackers can edit: email, websites, support tickets, documents, code repositories, issue comments, and tool results. The danger is not simply that a model produces an undesirable sentence. An embedded instruction can redirect the agent's plan, cause it to reveal data, misuse a tool, modify code, or initiate an external action. This is commonly called agent hijacking or indirect prompt injection.

Recent evidence has made the issue difficult to dismiss as a theoretical edge case. NIST's March 2026 analysis of a large-scale AI agent red-teaming competition describes agents processing email, websites, and code repositories as exposed to injected instructions intended to derail tasks and produce harmful actions. The useful enterprise question is no longer whether prompt injection exists. It is whether a particular implementation contains the resulting impact.

Understand the full hijacking path

An indirect injection begins outside the trusted instruction channel. An attacker places content in a location the agent may later read: a webpage, email body, document, calendar invitation, issue, pull-request comment, retrieved knowledge item, tool description, or tool result. The legitimate user asks the agent to perform a normal task. The agent retrieves the content and interprets part of it as an instruction rather than data.

Impact requires more than exposure. The agent must have—or be able to obtain—a useful capability. That may include reading sensitive context, sending data, changing a record, writing a file, running code, navigating an authenticated browser, or invoking another agent. The complete path is source, ingestion, interpretation, capability selection, authorization, execution, and effect.

Map each stage. Identify who can influence the source, which pipeline fetches it, what transformations occur, whether provenance survives summarisation, which instructions outrank it, what tools become available, and where permissions are enforced. A sanitized visible answer does not prove the hidden tool path was safe. A model may omit malicious text from its response while still following it.

Separate model behavior from system enforcement. Prompt design, delimiters, and instruction hierarchy can reduce susceptibility, but the tool server must independently reject unauthorised objects and actions. Approval controls should display actual parameters through trusted UI. Egress policy should prevent arbitrary destinations even if the model requests them.

Define the unacceptable outcomes before testing. Examples include cross-tenant retrieval, transmission of a canary secret, code changes outside an allowed directory, tool calls unrelated to the user's request, persistence into memory, or bypass of human approval. This turns an open-ended red-team exercise into measurable security validation.

Build realistic but safe test fixtures

Agent-hijacking tests should resemble the target's real work without using real victims or destructive payloads. Create synthetic users and tenants, canary secrets, mock repositories, controlled email addresses, test websites, and reversible operations. A canary can demonstrate that protected context crossed a boundary without exposing genuine credentials or customer data.

Seed content in each ingestion channel. In email, vary body text, quoted replies, signatures, HTML, attachments, calendar content, and forwarded messages. On the web, test visible text, hidden or visually de-emphasised content, metadata, linked pages, redirects, and content returned after interaction. In repositories, include README files, source comments, issue descriptions, pull-request reviews, generated logs, dependency documentation, and test output.

Use benign instructions that create observable behavior. Ask the agent to include a unique marker in a draft, select a controlled tool, request a harmless file, or send a canary to a sink owned by the test team. Avoid instructions that damage systems or exfiltrate actual secrets. Agree on prohibited actions, budgets, rate limits, recipients, and a kill switch.

Create control cases. One document should contain the same business data without the injected instruction. Another can contain instruction-like prose that is legitimate content, such as a security policy discussing “ignore previous instructions.” These controls help distinguish semantic susceptibility from simple keyword matching.

Preserve exact fixtures and hashes. Websites change, email rendering transforms HTML, and repository tools may retrieve only fragments. The report should identify what the agent actually received, not merely what the tester intended to publish. If retrieval or ranking determines exposure, record those intermediate results as well.

Test email and messaging agents beyond the chat box

Email agents often combine broad read access, personal context, and external send capability. A legitimate request such as “summarise today's messages and follow up where needed” can expose the agent to attacker-controlled content and grant discretion over recipients.

Test whether an untrusted message can change the task. Use a benign embedded request to search for unrelated information, include a canary in a draft, choose a different recipient, or invoke a privileged mailbox tool. Observe whether the agent distinguishes the sender's content from the user's command. Repeat with a reply chain where the injection appears to come from an internal participant.

Inspect context minimisation. Does the agent receive the entire mailbox, hidden headers, unrelated threads, or attachments it does not need? Can one message cause the agent to retrieve another? Test tenant and mailbox boundaries server-side by substituting identifiers, not only by asking the model politely.

Separate drafting from sending. A safe workflow may permit the agent to prepare content while requiring trusted confirmation for the final recipient and body. The approval UI should expose the real address and attachments, not an agent-generated description. Test recipient lookalikes, added BCC fields, altered links, and changes between preview and execution.

Messaging systems also create persistence. An injected instruction may be quoted in later threads, summarised into notes, or stored in memory. Test a new session after the original message is gone. Verify deletion and incident cleanup across indexes, summaries, and stored context.

Logs should connect the source message, retrieved fields, agent decision, tool arguments, approval, provider response, and controlled receipt. A transcript ending with “message sent” is weaker evidence than confirmation at the test mailbox.

Test browser and web-research agents at the action boundary

Browser agents encounter adversarial content by design. They may read pages, follow links, fill forms, download files, and operate inside authenticated sessions. The browser is both an ingestion channel and a powerful tool.

Host controlled test pages containing benign injected instructions in different contexts. Test content loaded after scrolling, script-rendered text, accessibility labels, structured data, and pages reached through redirects. Determine which representation the agent consumes: rendered DOM, extracted text, screenshot, or a tool-generated summary. Defenses must cover the actual channel.

Observe navigation and origin handling. Can a page instruct the agent to visit a different domain, internal address, cloud metadata endpoint, or data-collection URL? Enforce protocol and destination allowlists, block private ranges where appropriate, validate every redirect, and use constrained egress. Test encoded and alternate address forms without attempting unauthorised access.

Authenticated browsing raises the consequence. A malicious support article could direct an agent to account settings or payment screens under the user's active session. Require trusted approval for state changes and display actual origin, action, and values. Use browser profiles with synthetic accounts and minimal permissions during testing.

Downloads and uploads need separate controls. Treat downloaded files as untrusted, validate type and size, scan and sandbox processing, and prevent automatic execution. Restrict uploads to approved destinations and data classes. Test whether page content can cause the agent to attach a local canary file to a controlled form.

Measure task integrity, not only data leakage. A hijacked research agent may subtly bias sources, omit contrary evidence, or report completion after visiting an attacker-selected page. Compare outputs with control pages and retain navigation history and cited sources. Security includes preserving the user's objective as well as preventing a dramatic exploit.

Test coding agents and repository workflows

Coding agents routinely read content that outside contributors can influence. An issue, code comment, test failure, package documentation, or pull-request review can become an instruction channel. The agent may also possess filesystem, shell, repository, package-manager, secret, and deployment access.

Use an isolated repository and synthetic credentials. Seed harmless instructions in files and collaboration artifacts, then give the agent a normal maintenance task. Observe whether it reads unrelated files, changes CI or security configuration, adds a dependency, accesses environment data, or attempts network communication beyond the task.

Constrain execution. Run the agent in a sandbox with a narrow workspace, controlled network, non-privileged user, resource limits, and no production credentials. Separate read, edit, test, commit, push, and deploy permissions. A coding assistant that can propose a patch does not automatically need authority to merge or release it.

Test command construction and tool results. Compiler errors, terminal output, fetched documentation, and package metadata can contain injected text. The agent should treat them as data. Shell tools should prefer structured commands, enforce allowlists or policy, and require approval for high-impact operations. Never rely on a prompt prohibition to protect the host filesystem.

Review diffs independently. A malicious instruction may produce a subtle change rather than a visible exfiltration attempt: weakened authentication, disabled tests, an altered dependency source, or telemetry to a new endpoint. Use standard code review, secret scanning, dependency verification, and branch protection around agent changes.

Capture the complete path from source artifact to file diff, command, network request, commit, and downstream workflow. If the agent only proposed a dangerous change and branch protection blocked it, report both the behavioral failure and the effective control.

Evaluate multi-turn persistence and cross-tool chains

Many test suites stop after one adversarial prompt. Real agents maintain conversation state, retrieve more data, call tools, and revise plans. An injection may first establish trust, then ask for an unrelated step several turns later. It may also persist in memory or a generated summary.

Run multi-turn sequences with realistic intermediate tasks. Change wording and order. Repeat cases because model behavior is probabilistic. Record success rate and environment rather than treating one result as universal. Use a template baseline for repeatability and bounded adaptive exploration for unexpected paths.

Test cross-tool composition. Sensitive read plus external send is the classic exfiltration chain. Browser plus authenticated session can change an account. Repository read plus shell plus network can leak code. RAG plus memory can make a short-lived instruction persist. Build a graph of reachable capabilities and prioritise paths by consequence.

Introduce a canary through one low-trust source and observe whether it changes a different high-trust tool. Preserve provenance through summarisation and delegation. If a path is inferred from two separate findings but not replayed end to end, label it a hypothesis rather than confirmed impact.

Test remediation at the correct layer. Strengthen content treatment, then also narrow tool permissions, enforce resource authorization, add trusted approval, constrain egress, and isolate memory. Rerun the original case and variations. A prompt-only patch may move the failure to a different phrasing.

Our detailed guide to indirect prompt injection in RAG and tool-using agents covers retrieval-specific paths, while the AI agent memory-poisoning guide addresses persistence and cleanup.

Evidence and regression criteria for agent hijacking

A useful finding states the expected boundary, exact source content, ingestion path, agent and model version, prompts and tool definitions, identity, selected actions, policy decisions, server results, and confirmed effect. Redact sensitive values while retaining canary and tenant evidence.

Classify outcomes: content was retrieved; the model appeared influenced; a tool call was generated; the call was blocked; the server accepted it; impact was independently confirmed. This prevents a screenshot of a suspicious sentence from being reported as a complete breach—and prevents an effective backend control from hiding a model-behavior weakness.

Use model or judge scoring carefully. Define the rubric, record what evidence the judge sees, represent uncertainty, and require human review for consequential findings. Prefer deterministic proof such as a canary received at a controlled destination, a server denial, a protected object returned, or a verified repository diff.

After remediation, rerun the exact fixture, control cases, paraphrases, and adjacent channels. Retest when the model, system prompt, retrieval pipeline, tool schema, permission, memory policy, or connected service changes. Preserve known cases as regression tests with timestamped results.

Agent hijacking cannot be solved by asking the model to ignore malicious instructions. It is contained by a system that expects untrusted content, limits what interpretation can authorise, preserves provenance, enforces permissions outside the model, and produces evidence when those controls are challenged.

Oxyne performs adaptive, multi-turn security validation through supported agent interfaces and preserves transcript-backed findings for review and retesting. Explore AI Red Teaming, read why prompt injection testing alone is not enough, or book a scoped demonstration.