AI Email Agents and Prompt Injection: The Company Risk Explained

An attacker who cannot reach your employee's mailbox can still reach the agent that already has it.

AI email agents combine three capabilities that are each defensible on their own and dangerous together. They ingest content that an attacker can send unsolicited. They reason about that content using models that cannot reliably tell the difference between data and instructions. And they hold authenticated permissions to search, send, forward, schedule, and approve.

Security engineers have a name for this shape: the confused deputy. A program with legitimate authority is tricked by someone without that authority into using it on their behalf. In an email agent, the attacker supplies the instruction and your employee supplies the authority. The malicious text arrives as an ordinary message. The resulting action executes under a real identity, with real permissions, and looks entirely legitimate in the audit log.

The research published across 2025 and 2026 points to one uncomfortable conclusion. Prompt injection is not solved at the model layer, and there is no strong reason to expect it will be. Better instruction hierarchies and classifiers reduce naive attacks, and adaptive attacks route around them. The leading security position has moved accordingly, away from "detect every malicious prompt" and toward "assume some manipulation will succeed, and constrain what the agent can do afterward."

Key Takeaways

• Prompt injection remains unsolved at the model layer. Deployments that treat model robustness as their security boundary are relying on a control that current research says will keep failing.

• The risk changes character when an agent moves from recommending to executing. A compromised summarizer produces a misleading answer. A compromised agent sends, forwards, discloses, and approves under your employee's identity.

• Email is the worst-case input channel because an attacker needs no access to your systems to put content in front of the agent, and because mailboxes connect outward to calendar, storage, CRM, and payment workflows.

• EchoLeak and ShadowLeak both achieved data exfiltration through ordinary email with no user click, in products from two different vendors. Both are patched. The architecture, not the individual bug, is the lesson.

• The controls that hold are architectural: capability separation, least privilege per agent identity, policy enforced outside the model, and independent authorization of sensitive tool calls.

• Human confirmation is a real control only when it is rare, specific, and backed by enforceable limits. Telemetry on approval behavior suggests most confirmation designs fail that test.

What an AI Email Agent Actually Does

The word "agent" is doing a lot of work in vendor marketing right now, so start with what separates an agent from an assistant.

An assistant responds. You ask it to rewrite a paragraph, and it returns text. An agent observes state, plans a sequence of operations, selects tools, and executes them. In an email context, that means the system can read mailbox contents, decide that three steps are required, call the search tool, call the send tool, and call a calendar API, without returning to you between steps.

The functions on offer are useful, which is why adoption is moving quickly:

• Summarizing long threads and prioritizing an inbox

• Extracting tasks, deadlines, and commitments

• Drafting replies, and in some configurations sending them

• Forwarding messages and attachments

• Scheduling meetings and updating calendars

• Retrieving documents from connected cloud storage

• Updating CRM, ticketing, or HR records

• Initiating approvals, purchase requests, or workflow automations

Gartner has forecast that 40% of enterprise applications will include task-specific agents by the end of 2026, up from under 5% in 2025. Treat that as a directional statement about exposure rather than a measurement. The relevant point is the trajectory: the count of systems where an untrusted email can reach a privileged action interface is growing fast, and most of that growth is happening inside productivity tools that were never threat-modeled for it.

Microsoft frames the important transition as the move from reading to acting, and that framing is right. It is the line where prompt injection stops being an output-quality problem and becomes a security problem. Below the line, a successful attack makes your agent wrong. Above it, a successful attack makes your agent an insider.

Direct and Indirect Prompt Injection, and Why Only One of Them Scales

Prompt injection comes in two forms, and enterprise risk sits almost entirely in the second.

Direct prompt injection is a user deliberately feeding instructions designed to override the system's rules. This is the version that gets demonstrated in screenshots. It matters for abuse and policy circumvention, but the attacker and the victim are the same person, which limits what it can do to your organization.

Indirect prompt injection is malicious instruction embedded in content the agent retrieves or observes while doing its job. The user never sees it. The attacker never touches the AI interface. For an email agent, the carriers include:

• The body of an incoming message

• Quoted text buried in a long reply chain

• Calendar invitations and their description fields

• Attachments, including PDFs and office documents

• Documents pulled from connected cloud storage

• Web pages linked from an email and fetched by the agent

• Text rendered inside images, and image alt metadata

• CRM notes and support tickets the agent reads

• Tool descriptions and responses from connected MCP servers

OWASP ranks prompt injection first in its LLM risk taxonomy, and its agentic taxonomy breaks the agent-specific consequences into goal hijacking, tool misuse, and identity and privilege abuse. Those three categories map cleanly onto what an email agent can be made to do.

Most published coverage stops at that distinction. The more useful question is why email in particular turns indirect injection from a research curiosity into an operational risk.

Why Email Is the Worst-Case Input Channel

Not all untrusted input is equally dangerous. Email is close to the worst case on every dimension that matters.

Attackers can push content into the agent's environment without any access. This is the property that separates email from almost every other input channel, and it is the same property that made email the dominant delivery route for modern phishing attacks long before agents existed. To poison a web page an agent might visit, an attacker needs the agent to visit it. To poison a document in your SharePoint, they need to already be inside. To poison an email agent, they need your employee's address, which is usually public. Delivery alone completes the setup.

Email natively blends instruction and data. Business correspondence is full of legitimate directives: approve this, forward that to legal, update the record by Friday, use these wire details. A model reading a mailbox cannot fall back on a simple rule like "content is never instruction," because in email, content frequently is instruction. The distinction the model is being asked to draw is not merely difficult. In many messages it is undecidable without knowing who is authorized to ask for what.

Email carries authority signals that are trivial to forge. Titles in signature blocks, corporate formatting, a long reply chain implying prior agreement, a domain that looks close enough. These cues shape how a model weights the content it reads, in much the same way they shape how a hurried employee weights it. When an attacker operates from a genuinely compromised account inside a partner organization, the authority signal is not forged at all.

Mailboxes hold the material an attacker actually wants. Password reset links. Multi-factor codes. Contracts and term sheets. Legal advice. Customer records. Internal strategy. Identity documents sent by new hires. An agent with broad mailbox read access is, from the attacker's perspective, a search interface over your organization's most sensitive unstructured data.

The blast radius exceeds the mailbox. A single email agent may connect to calendar, contacts, cloud storage, browser automation, CRM, support, HR, procurement, and payments. Each connector extends what a successful injection can reach. The agent becomes a bridge between an untrusted input channel and a set of systems designed on the assumption that whoever reaches them has already been authenticated and authorized.

Agent output inherits organizational trust. When an employee reads a summary produced by the company's AI assistant, they tend to treat it as pre-validated, in a way they would not treat a raw forwarded email from an unknown sender. Attacker content that gets restated by your own agent gains credibility it did not earn. No architectural control addresses this, and it comes back later in this article.

How the Attack Actually Runs

The mechanics are consistent across nearly every documented case:

1. The attacker sends a message containing adversarial instructions to an address the agent has access to.

2. The instructions are concealed from human view using white-on-white text, one-pixel fonts, HTML that does not render visibly, content buried deep in a quoted chain, or text inside an image.

3. The user asks the agent to do something ordinary. Summarize today's mail. Find the invoices. Check for anything urgent.

4. The agent retrieves the attacker's message as part of that task.

5. The model treats the attacker's text as either an instruction to follow or authoritative evidence about what it should do.

6. The agent invokes a privileged tool.

7. The tool executes using the victim's credentials and connected accounts.

What comes out the other side depends on what the agent was permitted to do. Documented and demonstrated outcomes include exfiltrating message content, forwarding attachments to external addresses, sending deceptive replies from a real employee's mailbox, creating inbox rules or scheduled events for persistence, suppressing or misclassifying security warnings, altering CRM records, inviting external users to internal meetings, triggering procurement or payment workflows, and copying the malicious instruction onward into other systems and other agents.

Step three deserves attention. The user did nothing wrong. They did not click a link, open an attachment, or approve anything unusual. They asked their assistant to summarize their inbox. Every conventional user-focused control assumes a moment where the employee makes a decision that turns out to be bad, and here there is no such moment, because the exploitable interpreter is not the person. It is the agent.

What the Research Actually Shows, and What It Doesn't

There is now a substantial body of published work on this, and the figures are frequently quoted without their conditions, which does real damage to the argument.

The most direct evidence on email comes from Control at Stake, a 2025 study that built an automated evaluation pipeline and tested email agent hijacking across 14 agent frameworks, 63 agent applications, 12 LLMs, and 20 email services. That produced 1,404 distinct email agent instances. All 1,404 were successfully hijacked, at an average of 2.03 attempts.

That number invites misreading, so state the limit plainly. These were instances the researchers constructed and evaluated under their own attack assumptions. It is not a survey of production email agents in the field, and it does not mean every commercial email assistant is trivially exploitable today. What it does establish is that the vulnerability is not a defect in one vendor's implementation. Across a wide range of frameworks, models, and mail providers, the combination of email ingestion and tool access produced the same failure.

Two benchmarks give a sense of how often injection succeeds under controlled conditions. InjecAgent, an early benchmark covering 1,054 cases across 17 user tools and 62 attacker tools, found that a ReAct-prompted GPT-4 agent followed indirect attacks in about 24% of tests, with reinforced attack variants performing substantially better. LivePI, a 2026 benchmark that evaluated agents in a production-like environment with live but controlled email, chat, web, repository, file, and wallet interfaces, reported attack success rates between 10.7% and 29.6% across frontier models.

The LivePI result matters more for its second half than its first. In one evaluated configuration, a two-layer defense combining prompt filtering with pre-execution tool authorization intercepted every tested malicious-goal completion. Both halves of that finding are the argument of this article in miniature. The models remain manipulable, and manipulation does not have to become a harmful action, provided something other than the model decides what executes.

One more finding closes a practical gap. An attacker's message only matters if it enters the agent's context, which for a long time was the weak link. Recent work on retrieval-aware injection attacks that directly, optimizing content so search and retrieval systems surface it for likely queries. One 2026 study reported near-total retrieval success across 11 benchmarks and eight embedding models, at a cost of roughly $0.21 per targeted query, and over 80% exfiltration success in one poisoned-email multi-agent experiment. In practice, an attacker can craft a message designed to be the one your agent pulls up when someone asks about onboarding, or invoices, or recent security notifications.

The caveats on all of this are load-bearing.

Benchmark attack-success rates are not incident rates. Nothing in this literature tells you what fraction of real corporate email agents have been compromised. Attack success in these studies depends on the agent architecture, the model, the available tools, the system prompt, how much the attacker knows, how many attempts they get, and how the researchers defined success. Two studies reporting different percentages are usually not measuring the same thing, and comparing them directly is not valid.

The threat is real, and the ceiling is lower than the headlines suggest. The UK's NCSC, assessing AI's near-term impact on cyber threats, concluded that fully automated end-to-end advanced attacks remain unlikely through 2027, while noting that direct and indirect prompt injection are already being used against AI systems. That is the right calibration for a serious and present architectural weakness that is not an autonomous adversary.

EchoLeak and ShadowLeak: Two Vendors, One Root Cause

Two disclosed vulnerabilities moved this from theory to demonstrated fact in shipping enterprise products. They are usually covered separately as news items. Read together, they make a single argument.

EchoLeak (CVE-2025-32711) was disclosed by Aim Security researchers against Microsoft 365 Copilot in June 2025, carrying a CVSS score of 9.3. The published analysis describes it as the first real-world zero-click prompt injection exploit in a production LLM system.

The attack required one crafted email. When Copilot later pulled that message into its retrieval context during normal operation, it executed the attacker's embedded instructions and exfiltrated organizational data, including chat history, OneDrive files, SharePoint content, and Teams messages. The recipient did not need to open the message, click anything, or take any action at all.

Getting there required chaining several bypasses, and two are worth naming for what they imply. The researchers evaded Microsoft's cross-prompt injection classifier, the control built specifically to catch this class of attack. They then used reference-style Markdown and auto-fetched images to move data outward, abusing a Microsoft Teams proxy that the content security policy already permitted. Microsoft issued a server-side fix, confirmed that customers needed to take no action, and reported no known exploitation in the wild.

ShadowLeak followed a similar path through a different vendor's architecture. Researchers at Radware disclosed an attack against OpenAI's ChatGPT Deep Research agent when connected to Gmail. Hidden instructions embedded in email HTML, using white-on-white text and microscopic fonts, directed the agent to collect personal information, encode it, and append it to an attacker-controlled URL. As with EchoLeak, the target did not need to open or interact with the message.

The distinguishing detail is where the exfiltration happened. The data left from OpenAI's own cloud infrastructure rather than from the user's device or network, so it never crossed an enterprise boundary where local or network defenses could observe it. Radware reported the issue in June 2025, OpenAI fixed it in early August, and it was marked resolved in September.

Putting these side by side supports three conclusions.

This is not a vendor problem. Two different companies, two different architectures, two different model families, same root cause. Both systems retrieved attacker-controlled content and acted on it.

Both are patched, and neither has known in-the-wild exploitation, so anyone citing them as active threats is overstating the case. Their value is diagnostic. They show the failure mode is architectural, that it survives contact with well-resourced security teams, and that researchers found it rather than the vendors' own controls.

Most usefully, both defeated protections built specifically to stop them. EchoLeak got past a dedicated prompt injection classifier. ShadowLeak's exfiltration path was invisible to the enterprise security stack entirely.

Where the Attack Surface Extends Beyond the Inbox

Scoping this problem to "email body text" understates it in several directions.

Attachments and retrieved documents carry instructions as readily as message bodies, and an agent that opens a PDF to answer a question about it has ingested whatever is inside, including text layers a human reader never sees.

Calendar invitations are a delayed trigger. An invite sits in the calendar until an agent processes the day's schedule, at which point its description field is read like any other content. The gap between delivery and execution can be arbitrary.

Retrieval systems are now an explicit target rather than an incidental path. An attacker who understands what queries your organization runs can write for the retriever rather than for the reader.

MCP connectors and tool metadata move the injection out of the content entirely. Poisoned tool descriptions or manipulated server responses influence an agent's behavior without any malicious email existing. Recent security analyses of the Model Context Protocol identify tool poisoning and implicit trust between components as significant weaknesses in exactly the productivity integrations email agents depend on.

Agent memory turns a one-time injection into a persistent one. An instruction written into long-term memory survives the session that introduced it and influences behavior indefinitely.

Cross-agent propagation is the compounding case. A malicious instruction can be copied into a generated summary, a forwarded message, a CRM note, a shared document, or another agent's task context. The Morris II research prototype demonstrated self-replicating prompts moving through generative AI email ecosystems while attempting to steal data. Label that accurately: Morris II was a controlled proof of concept, not an observed worm in the wild. It established that propagation through AI-consumed content is feasible, which is a claim about architecture rather than about current attacker activity.

Why Detection Cannot Be the Security Boundary

The instinctive response to malicious content is to detect and filter it. That instinct produces useful tooling and a false sense of where the boundary sits.

Start with what changed about the attacks. Early prompt injections used explicit override language, most famously "ignore previous instructions." Those are easy to catch and largely a solved problem. Current attacks look nothing like that. They impersonate internal process documentation. They claim an unusual action is required for security or compliance reasons. They fabricate authorization. They present data exfiltration as a routine submission step in a workflow the agent believes it is completing correctly. They break a harmful sequence into individually innocuous steps. OpenAI's own position is that sophisticated prompt injection has come to resemble social engineering more than instruction override, and that detecting mature injection becomes about as tractable as detecting deception in general.

Anthropic's report on an AI-orchestrated espionage campaign illustrates the technique from the attacker's side. The operators decomposed the intrusion into small tasks that looked benign in isolation, and told the model it was an employee of a legitimate security firm conducting authorized testing. No single request looked like an attack. The same context-stripping logic is what makes a well-written email injection work.

The field's central disagreement sits here, and it deserves an honest airing rather than a confident answer.

One camp treats prompt injection as a vulnerability that will yield to engineering: better instruction hierarchy training, stronger separation between system and user content, improved classifiers. OpenAI has reported real gains from instruction hierarchy work, and those gains are not nothing.

The other camp argues the problem is structural. Instructions and untrusted data occupy the same context window as undifferentiated natural language, and the model is left to infer which statements carry authority. Abdelnabi and Bagdasarian push this furthest: a sufficiently capable attacker can construct a context in which a prohibited information flow looks entirely legitimate, while controls strict enough to prevent it will also block legitimate work. Their conclusion is not that defense is hopeless, but that universal model-level detection is probably unattainable, and security policies therefore have to specify which information flows are acceptable rather than trying to recognize bad intent.

The practical resolution does not require picking a side. Model robustness will improve. It cannot be the authorization boundary, because a boundary that fails 10% of the time against a motivated attacker is not a boundary. EchoLeak's classifier bypass is the concrete demonstration.

None of this makes detection worthless. Classifiers and filters remain a useful layer. They stop unsophisticated attacks cheaply, generate the telemetry that reveals campaigns, let you quarantine suspicious content, raise the approval threshold for actions influenced by flagged material, and feed incident response and red-team programs. Deploy them, and do not let them be the thing standing between an attacker's email and a wire transfer.

A Graded Authority Model for Email Agents

If the model cannot be trusted to decide what is safe, authority has to be granted deliberately rather than inherited. A tiered model makes that concrete.

Tier 0, Observe. Search, classify, summarize. The agent reads and produces text for a human. No state changes anywhere. This is where a mailbox assistant should sit by default, and a surprising share of the value people want from email agents is available at this tier.

Tier 1, Recommend. The agent composes a proposed action and hands it to a person. It drafts the reply but cannot send it. The output is a suggestion, and the human remains the actor.

Tier 2, Reversible action. The agent changes state in ways that are cheap to undo: applying labels, filing messages, saving drafts, proposing calendar events that require acceptance. Errors here are annoying rather than damaging.

Tier 3, External communication. The agent sends mail, shares documents, or otherwise transmits outside the organization. This is a hard line. Outbound communication is difficult to reverse, discloses information permanently, can create contractual and reputational consequences, can be used to impersonate an employee, and is one of the primary ways an injection payload spreads. Everything at this tier warrants confirmation designed to the standard described below.

Tier 4, High-impact action. Financial transactions, payment or banking detail changes, credential and access modifications, legal commitments, administrative changes to identity systems. These require independent approval and verification through a channel other than the one carrying the request. If an email prompted it, email cannot confirm it.

The governing principle: an email-reading agent should start at Tier 0, and every step up should be an explicit grant tied to a specific business need. Technical availability is not authorization. The fact that a connector exposes a send endpoint is not a reason for the summarization agent to hold it.

The Controls That Actually Hold

Assume manipulation succeeds. What stops it from becoming damage?

Separate reading from acting. Use distinct components, and distinct identities, for reading and classifying mail, drafting proposed actions, authorizing actions, and executing them. A mailbox summarizer does not need send, forward, or delete privileges, and granting them to save an integration is how a low-risk deployment quietly becomes a high-risk one.

Apply least privilege to every agent identity. Agents get their own identities, never shared human credentials. Narrow OAuth scopes. Access to specific mailboxes and folders rather than tenant-wide reach. Recipient and domain allowlists for anything that sends. Time-limited credentials and revocable sessions. Explicit limits on attachment access. Identity and privilege abuse is a named category in OWASP's agentic taxonomy for good reason: it is where most of the damage in this class of attack is realized.

Enforce policy outside the model. A deterministic policy engine should evaluate every sensitive action independently of whatever the model concluded. Rules that belong in that engine for an email agent:

• No sending to external domains without confirmation

• Never forward messages carrying a confidentiality label

• Never attach files retrieved from another connected system to outbound external mail

• Never change payment or banking details on the basis of email content

• No creation or modification of inbox rules through the model

• Never transmit credentials, tokens, or authentication codes

• Require second-channel verification for banking, supplier, payroll, and access changes

• Block any tool call whose parameters derive solely from untrusted content

The model proposes. It does not get to decide whether the proposal is authorized.

Track provenance. For every parameter in a sensitive tool call, the system should know where the value came from: the user's instruction, organizational policy, an email body, an attachment, a retrieved web page, model memory, or another tool's output. This is what makes the last rule above enforceable. An action whose destination, justification, or payload originates entirely in an untrusted message should not execute without independent validation, and that rule cannot be applied without provenance data.

Authorize tool calls independently. Before execution, something other than the reasoning model should inspect the tool name, the parameters, the destination, the classification of the data involved, the transaction value, whether the action is reversible, whether it matches the user's actual stated objective, and which content influenced the decision. Research on causal attribution of tool invocations exists precisely to keep this check from depending on the model that may already be compromised. The LivePI result suggests this layer does most of the work.

Sandbox content processing. Attachments, followed links, and browser operations should execute in isolated environments with no ambient credentials, restricted network access, read-only file systems where feasible, and no access to SSH keys or password stores. Keep those environments short-lived.

Log everything, immutably. Retrieved messages and documents, trust classifications, model and policy versions, proposed plans, tool calls and parameters, confirmation screens shown, user decisions, data destinations, policy denials, memory writes, and cross-agent communication. The logs must resist modification by the agent itself, which is not the default in many current deployments. Without this, an agent compromise is not investigable.

Designing Confirmation That Still Means Something

Human approval is the control most organizations lean on, and it is weaker than it looks.

Anthropic has reported telemetry showing users approving roughly 93% of permission prompts in Claude Code. That figure comes from a coding-agent context rather than an email one, and the populations differ, but the mechanism transfers directly. When a system asks for approval constantly, approval stops being a decision and becomes a reflex.

Several forces push in the same direction. Volume produces habituation. The agent supplies its own persuasive explanation of why the action is necessary, and that explanation can itself be shaped by attacker-controlled content. Users often lack the context to evaluate what they are approving. Productivity pressure builds, and organizations respond by removing confirmations, usually starting with the ones that fire most often, which are not necessarily the ones that matter least.

A confirmation worth having shows the user the exact action, the exact recipients, the exact data or attachments about to be disclosed, the originating message that prompted it, any external domains involved, and the specific policy concern that triggered the prompt. It should not ask "Allow?" and it should never let the agent narrate its own risk assessment in language an attacker may have influenced.

The design rule that follows: confirmation is a real control only when it is rare, specific, and backed by enforceable limits. Confirming dozens of actions a day is not oversight. It is a clicking habit serving as a last line of defense.

The Human Layer Architecture Cannot Cover

Every control described so far governs what the agent does. None of them govern what the person does with what the agent produces, and that is a live attack surface.

Security researchers demonstrated that hidden content in an email could manipulate Gemini-generated summaries in Google Workspace, causing the summary to display fabricated security warnings and attacker-chosen contact details that appeared nowhere in the visible message. No autonomous action was involved. The agent simply told the user something false, in the organization's own voice.

An employee who receives a suspicious email from an unknown sender applies some skepticism. An employee who reads a summary from the company's AI assistant, telling them their account needs attention and here is the number to call, applies considerably less. Attacker content that passes through your agent comes out the other side wearing your organization's credibility, which compounds a problem that already exists with AI-generated phishing that reads as legitimate correspondence. The 2026 Verizon DBIR continues to find the human element in the substantial majority of breaches, and agent-mediated content does not remove the human from the loop. It changes what the human is looking at.

Two practices matter here, and neither is technical.

The first is an out-of-band verification habit that is indifferent to who or what surfaced the request. Payment changes, banking detail updates, credential resets, MFA enrollment, supplier changes, payroll modifications: verified through a known channel, using contact details the organization already holds, regardless of whether the request arrived from a person, an email, or the company's own AI summarizing one. The habit has to be reflexive, because the whole point of these attacks is that the request will look correct, and building that reflex is what role-based training against AI-driven social engineering is for.

The second is reporting. A poisoned message only gets investigated if someone flags it, and a fabricated warning inside an AI summary is exactly the kind of anomaly an employee notices and then does nothing about, because there is no obvious place to send it. Whatever the reporting path is, it needs to be one action, and it needs to cover agent output as well as raw email.

To be direct about the limits: none of this prevents prompt injection. Training does not make a model better at distinguishing data from instructions, and any vendor implying otherwise is selling something. What the human layer addresses is the person at the other end of a compromised output, at the moment they decide whether to act on it.

Questions Worth Tracking

Several parts of this remain unsettled, and naming them is more useful than papering over them.

Liability has no clear answer. When an agent takes an unauthorized action, the candidate responsible parties include the agent developer, the model provider, the enterprise that deployed it, the connector or tool provider, the identity administrator who granted the scopes, the user who approved the action, and the external sender who supplied the injection. Existing contractual and negligence frameworks were not designed for action chains with that many contributors, and attribution is hard when the outcome emerges from model behavior, tool configuration, and attacker content together. Organizations deploying agents should be reading their vendor agreements with this in mind now, rather than after an incident.

Whether autonomous outbound email belongs in high-risk environments is unresolved. The productivity case is real in customer support, scheduling, and routine internal workflows. The counterweight is that outbound mail is irreversible and carries disclosure, contractual, fraud, and impersonation exposure. The compromise most organizations land on is autonomous drafting internally, constrained sending for a small set of low-risk templates, and explicit approval for anything external or unusual. In regulated sectors, the honest answer may be that the productivity gain does not justify the exposure yet.

The metric to demand from vendors is utility under attack. A block rate on a static benchmark tells you very little, because those benchmarks are what defenses get tuned against. What matters is how much genuine work an agent completes while an adaptive attacker is trying to subvert it. Research is moving toward measuring exactly this, and it is a fair question to put to anyone selling you an agent platform.

Top 5 AI-Powered Security Training Platforms for Companies

A necessary caveat before the list: none of these platforms prevent prompt injection. Prompt injection is defeated, to the extent it can be, by architecture. What security training platforms address is the layer described above, where an employee acts on output that a compromised agent produced, approves a request that looks routine, or fails to verify an instruction through a second channel. That gap is not covered by any amount of tool authorization. Evaluate these tools for that purpose and not as a control against injection itself. For a broader comparison across the category, see our breakdown of security awareness training platforms for 2026.

Listed alphabetically.

Brightside AI

Brightside is an AI-era simulation platform built around multi-vector realism rather than content-library breadth. It runs email phishing simulations, an AI vishing simulator with cloned or preset voices, and hybrid attacks that pair a voice call with a trackable phishing email as one coordinated workflow. Training content is delivered through Brighty, a scripted interactive course experience, and the admin portal reports on a full simulation funnel from delivered through opened, clicked, entered, and reported.

The relevance to agent-era risk is the emphasis on multi-channel verification behavior. The reflex to confirm an unusual request through a second channel is the same reflex whether the request arrives by voice call, email, or an AI-generated summary. Brightside also offers a Report Phishing add-on for Gmail and Google Workspace that gives employees one-click reporting, routes genuine threats to the security team with full headers while crediting reported simulations back to the employee, and requests least-privilege access to only the reported message. That is reporting and training tooling rather than filtering or detection.

Pros

• Phishing, vishing, and hybrid voice-plus-email simulations in one platform

• AI-generated caller personas, opening messages, and recommended attack strategies for vishing scenarios

• Simulation cooling period prevents reusing the same domain against an employee within three months

• Multilingual coverage across EN/FR/DE/IT/PL/ES/NL and more, with additional languages and voices added on request

• Integrates with Google Workspace, Microsoft AD, Okta, and Vanta

Cons

• Narrower content library and ecosystem than the large incumbent suites

• Brighty courses are scripted rather than live conversational AI

• No real-time behavioral monitoring

• Deepfake video simulation is a managed service for executive scenarios rather than a self-serve feature

Hoxhunt

Hoxhunt combines adaptive phishing simulations with behavioral science and heavy automation, aiming at measurable behavior change rather than completion rates. Training difficulty adapts per user based on prior performance, and the platform is built around sustaining reporting rates over time rather than driving click rates to zero once.

It suits organizations that already accept the premise that awareness training should be measured behaviorally and want the program to run with minimal administrative effort.

Pros

• Strong adaptive personalization and automation

• Behavior-change measurement rather than completion tracking

• Good engagement and reporting-rate outcomes

Cons

• Email-centric relative to platforms covering voice and other channels

• Enterprise-oriented pricing and onboarding

• Less suited to organizations wanting heavy manual control over campaign design

KnowBe4

KnowBe4 is the largest incumbent, with a training library well beyond a thousand modules, extensive phishing template coverage, and a mature compliance and reporting stack. Its scale is the product. For organizations that need broad topic coverage, many languages, and audit-ready reporting across a large workforce, few alternatives match the breadth.

Pros

• Very large content and template library, frequently updated

• Mature compliance reporting and administrative tooling

• Broad integration ecosystem and established procurement path

Cons

• Content can feel generic relative to AI-native competitors

• Simulation realism is a weaker point than library breadth

• Volume of available material can require real effort to curate

Proofpoint

Proofpoint's security awareness offering is most valuable to organizations already running its email security stack, because the training connects to threat telemetry from the same vendor. Its people-risk tooling identifies frequently attacked individuals using real attack data and can enroll employees who fail simulations into targeted learning paths.

Pros

• Training driven by the organization's own threat telemetry

• Identification of the most-attacked users based on real attack data

• Multiple simulation types and wide language coverage

Cons

• Value depends substantially on using Proofpoint email security

• Less customization than smaller, more flexible platforms

• Enterprise complexity for mid-market buyers

SoSafe

SoSafe is a European platform with a strong data-protection posture and GDPR alignment, combining behavioral-science-based training with phishing simulation and human risk reporting. It is a frequent shortlist entry for EU organizations with regulatory obligations under frameworks such as NIS2, where data residency and processing terms form part of the evaluation.

Pros

• Strong GDPR and EU data-protection positioning

• Behavioral science underpinning the training design

• Clear human risk reporting for compliance audiences

Cons

• Less multi-vector simulation depth than specialist platforms

• Content breadth below the largest incumbents

• Strongest fit is European, and less compelling elsewhere