What launched
Both products target email that can move money or manipulate an AI assistant. In the vendor's own description, the two products work like this:
- Intent Workflows holds payment, payroll and executive-account requests for verification before anyone acts on them.
- AI Instruction Intercept stops hidden instructions in a message before an assistant such as Microsoft 365 Copilot reads them.
Both are said to be available now for Microsoft 365 and Google Workspace. They are meant to run alongside a company's existing email security, not replace it.
StrongestLayer's public product page describes the deployment model. It connects through the Microsoft Graph or Google Workspace APIs, with no MX record changes. The company advertises a 15-minute setup. That figure is a vendor estimate, not a tested result.
Intent Workflows: verify the action, not the verdict
The scenario here is vendor email compromise. A criminal takes over a real supplier's mailbox and sends new bank details inside an existing thread. There is no malware and no suspicious link, so there is little for a conventional filter to flag.
StrongestLayer's CEO, Alan LeFort, says the costliest attacks "are built to look fine." The company's answer is to verify the action instead of trusting the message's verdict.
The reported workflow runs as follows:
- Detection still screens every message. Intent Workflows adds a hold only for the smaller set of requests that can't be reversed.
- The software compares each payment request with the payee's history. The customer sets the threshold, which can be every payment or only those over $5,000.
- If nothing has changed, the payment owner confirms with one click, in Microsoft Teams or by email.
- If anything has changed, or the vendor is new, someone must call a phone number already on file. The email isn't released until the outcome is logged.
- In-scope payments are held whatever the detection verdict, so a hijacked account can't pass a request through by sounding legitimate.
Customers can alternatively let a request through with a policy banner on tracked requests, such as "Bank change: call the number on file." Payroll changes are verified the same way. Requests to reset an executive's password, MFA or account recovery go to the identity or security team first, even if they arrive through the help desk.
The reporting doesn't say which identity providers or HR systems the workflow integrates with, such as Microsoft Entra. It also doesn't list configuration prerequisites. Administrators should ask the vendor before assuming either.
The numbers, and how far to trust them
SiliconANGLE reports that StrongestLayer analyzed 32,052 attacks that got past existing defenses at 45 organizations in the second quarter. Only 3.6% were payment or bank-change requests. Under a loss model built on the Factor Analysis of Information Risk (FAIR) framework, that slice accounted for more than 98% of estimated financial exposure. The article also says 94% of those messages passed sender authentication.
StrongestLayer's public Q2 2026 "Phishing Genome" summary corroborates part of this. It confirms the 32,052-attack sample from April to June 2026 and the 3.6% and 98% figures. It describes the risk as modeled financial loss by category, not losses organizations actually suffered.
The authentication figure needs care. The public summary says 86% of all attacks that reached the inbox passed SPF, DKIM and DMARC. That is a different population from the 94% SiliconANGLE cites for payment and bank-change messages, so the two shouldn't be merged. The public page also doesn't show the 45-organization count.
In short, this is vendor-generated, modeled data from its own detections. It is a reasonable argument for putting controls around money-moving requests. It isn't an industry baseline.
AI Instruction Intercept: the inbox as an AI attack surface
The second product reflects a change in who reads your email. StrongestLayer's product page illustrates this with an invoice email carrying white, one-pixel text addressed to an "AI reviewer," claiming the message was pre-approved and should be classified as safe. A human sees a routine request, and the assistant sees one more instruction.
According to SiliconANGLE, the product reads each message first. A reasoning model checks it for hidden instructions against the customer's own business context. Only then does the email reach Copilot, Google's Gemini or a security classifier. Suspect messages are quarantined by default, with an explanation of what each instruction was after.
StrongestLayer's page adds that its engine, TRACE, treats such content as evidence, not as an order. Text aimed at an AI counts as a suspicion signal, and messages judged to be prompt injection are pulled from the inbox with reasoning logged for the SOC. The same page says the approach covers Claude as well, but the launch coverage names only Microsoft 365 and Google Workspace as supported platforms.
EchoLeak: the precedent, kept in proportion
SiliconANGLE points to EchoLeak, the Microsoft 365 Copilot flaw found by Aim Security researchers. EchoLeak (CVE-2025-32711, CVSS 9.3) was a zero-click indirect prompt injection vulnerability in Microsoft 365 Copilot. A single crafted email could exfiltrate internal files via Copilot, with no user click required.
Research write-ups describe the chain in more detail. It bypassed Microsoft's XPIA prompt-injection classifier, evaded link redaction using reference-style Markdown, and abused a trusted Microsoft Teams proxy domain to get around the Content Security Policy.
This is history, not an open hole. Reco reports that Microsoft shipped a server-side fix in May 2025, weeks before public disclosure, and that customers didn't need to take any action. The same source notes there are no documented real-world attacks exploiting this specific CVE. Secondary sources differ on the exact patch timing. Some place the fix in June 2025, and one source's May 2026 date looks inconsistent with the rest. The reliable point is that it was fixed server-side.
EchoLeak matters here for what it showed. Email is a delivery channel for attacker text into a model with broad access to a tenant's data, and a classifier inside the assistant's own stack can be bypassed. StrongestLayer's pitch is a separate check that doesn't depend on the assistant. Its co-founder Joshua Bass argues the inbox is the first place to stop prompt injection, because all an attacker needs is an address.
What admins should weigh
For Intent Workflows:
- Decide your payment threshold. Every payment is safer but noisier, while a $5,000 floor trades some coverage for fewer interruptions.
- Assign verification owners, and make sure the "number on file" is maintained and trustworthy. A compromised vendor record defeats out-of-band calls.
- Plan for exceptions and audit logging, since the release is gated on a logged outcome.
- Treat executive-reset routing as an identity policy question, not only an email one.
For AI Instruction Intercept:
- Ask about quarantine behavior, false-positive handling and what is retained. The vendor says email content is processed in memory and only metadata, verdicts and reasoning traces are kept. That is the vendor's statement, not an audit finding.
- Remember it complements, and doesn't replace, Copilot's own protections, least-privilege access to data, and Microsoft's patching.
What isn't established: No pricing, independent test results, false-positive rates, customer outcomes or detailed Microsoft tenant permissions were available. The vendor's page claims under 1% false positives, but that is marketing, not a measured benchmark.
Bottom line
The most useful idea here is the process, not the AI. Hard-to-reverse requests such as bank changes, payroll changes and executive account resets should require out-of-band confirmation, whatever an email filter thinks. Organizations can adopt that discipline with or without StrongestLayer. The second idea is that AI assistants now read your mail too, so prompt injection is an email security problem. Whether this vendor's implementation delivers will depend on testing in your own tenant.