AegisAI Perspectives · 120
Multi-agent AI in email security splits one email across specialized agents for headers, links and text, then weighs their findings into a single verdict.
See it on your own Google Workspace or Microsoft 365 tenant. No MX change.
Or get the Q3 2026 State of the AI Attack report (free, instant download)
Not ready for a demo? Check your domain (free, about 10 seconds).
Multi-agent AI in email security splits the judgment of one email across specialized AI agents, each reading one part, then weighs their findings into one verdict5. AegisAI says it plainly: "Reputation, intent, policy and headers are checked in parallel."18 In one lab study, one model reading the whole email had a 20.47% false positive rate, against 2.73% for the multi-agent design32.
It means the email is read by several agents with narrow jobs instead of one model reading everything at once. In the MultiPhishGuard research system, five cooperative agents (text, URL, metadata, explanation simplifier and adversarial) share the work, and their contributions are weighted for each email1.
The split changes false alarms: when one LLM processed the entire email, the study measured a false positive rate of 20.47%. The multi-agent design reached a false positive rate of 2.73% and a false negative rate of 0.20%. Both ran on 979 phishing emails and 3,000 legitimate emails4, so treat them as lab figures, not results on your mail.
For the wider loop an agent runs, from reading to acting, see how agentic AI is applied to email security. Ask any vendor for its own false positive rate on your mail before you rely on a lab figure.
Short on time? Watch the explainer, or book a demo.
Take one email that asks accounts payable to update a supplier's bank details. Here is the order a multi-agent system works in, and what each agent hands on.
The metadata agent reads the headers and the reply-to field, plus the sender authentication records (SPF, DKIM, DMARC), and flags anomalies6. A pass here is not a verdict: SPF checks only the MAIL FROM domain and ignores the domain in the From address13.
The URL agent extracts every link, checks it for obfuscation, scores the domain's reputation and follows redirects toward malicious sites7. Our bank change email may hold no link at all, so this agent reports nothing to weigh.
The text agent reads the body for suspicious patterns and textual signs of malicious intent27. Here it finds the request itself: new bank details, sent with urgency.
A context step compares the request with what this sender normally asks for. It matters because BEC often comes from legitimate business accounts that were compromised15, so the headers can all pass.
Each agent returns a verdict with a confidence score and a rationale.
A combining step weighs those verdicts for this email. With suspicious links it leans on URL analysis; with an inconsistent sender it leans on metadata8.
An explanation step turns the technical outputs into a plain-language reason a person can read9.
The system acts on the verdict, from delivery to removal, and stores the reason with the action.
Write down which of these eight steps each vendor runs before you compare them.
Each agent gives a verdict with a confidence score, and a combining step decides how much each one counts for this email. In MultiPhishGuard the weights are learned, with contributions weighted using Proximal Policy Optimization.
The combining step is a weak point: if the weights favor authentication, a compromised legitimate account scores clean on headers and the text agent's finding is outvoted. A single model has no such step, which is one reason it raised far more false alarms in the study.
Ask each vendor to show the per-agent verdicts behind one sample decision, not only the final score.
Every agent that reads message text reads attacker-written text. Indirect prompt injection happens when an LLM accepts input from external sources, such as websites or files10, and an email body is exactly that. The UK NCSC says prompt injection may never be totally mitigated in the way SQL injection can be11.
The NCSC's answer is design: deterministic, non-LLM safeguards that constrain what the system can do12. In email, that means the removal action sits behind limits an injected sentence cannot change.
Lures are getting harder to spot, too: fully AI-automated phishing emails reached a 54% click-through rate, against 12% for arbitrary phishing emails16.
Ask which actions an agent can take on its own and which sit behind a fixed rule.
These test the multi-agent design; the questions on autonomy and read-only trials are in how to choose agentic email security.
Send these seven questions in writing before the first demo.
| Criterion | One model reads the whole email | Separate agents per part | AegisAI |
|---|---|---|---|
| What is read | The entire email in one pass | Each part by its own agent: headers, links, body | Reputation, intent, policy and headers in parallel |
| How the verdict is made | One model's output | Per-agent verdicts weighted per email | A confidence score and plain-language evidence19 |
| Reason a person can read | No separate explanation step | An explanation step writes it | Its reason in plain language24 |
| False positives in the study | 20.47% | 2.73% | No published figure on this dataset |
| Blocking before delivery | Possible when placed in the mail path | Depends on placement | No edge. It reads mail through the API after delivery |
The last two rows give AegisAI no edge: it publishes no figure on the study's dataset, and it reads mail after delivery. Fill one copy of this table per vendor during the trial.
AI agents investigate every inbound email for what it is trying to do, and remove the ones that fail from every mailbox they reached. Reputation, intent, policy and headers are checked in parallel. Every verdict comes with a confidence score and plain-language evidence. Convicted mail is pulled from every mailbox, forwards included20. Runs in monitoring mode first22.
Illustrative example, figures are fictional: Harbor Pine Foods (fictional) receives an email from its real packaging supplier at 09:12 asking accounts payable to use a new bank account. The metadata agent finds that every sender check passes (SPF, DKIM, DMARC), because the supplier's own mailbox was taken over. The URL agent finds no link. The text agent flags a payment change sent with urgency. The context step finds the supplier has sent 46 invoices in two years and never changed bank details by email. The combining step weights the text and context findings over the clean headers, and the verdict is remove, with a three-line reason for the analyst. The analyst confirms by phone with a known contact and closes the case.
Run a walk like this on one real removed message from your trial.
Track three numbers during a monitoring-mode trial, each from a log you can export.
Put the three figures next to your current stack on day 30 and decide on them.
It is a design where several specialized AI agents each read one part of an email, and a combining step weighs their verdicts into one decision.
In one study it was. A single model processing the whole email had a 20.47% false positive rate, against 2.73% for the multi-agent design. Measure it on your own mail before you rely on it.
In the MultiPhishGuard design, the metadata agent reads headers and sender authentication records, the URL agent reads links, and the text agent reads the body for malicious intent.
Yes, that is indirect prompt injection, where an LLM takes in external content. The NCSC advises deterministic safeguards that constrain what the system can do.
Because BEC often comes from compromised legitimate accounts, and SPF checks only the MAIL FROM domain. The text and context agents judge the request itself.
