AegisAI Perspectives · 094
API-based email security connects to Microsoft 365 as an admin-approved Graph app that reads mail after delivery and removes threats, with no MX change.
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)
API-based email security is an app that authenticates to the Microsoft Graph API, scans messages in Microsoft 365 after delivery to user mailboxes and removes the ones it judges malicious3. AegisAI reads mail through the Microsoft 365 API after delivery, with no change to mail routing18.
It reads and acts on mail that Exchange Online has already delivered. Microsoft describes services that authenticate, use the Microsoft Graph API to scan messages after delivery, and remove messages they believe to be malicious or unwanted. Mail keeps its normal route, so the domain's MX record stays with Microsoft 365. A gateway works the other way: for mail to reach a third-party filter first, the domain's MX record must point to that provider17.
Microsoft notes this integration typically requires granting the service full access to mailboxes4. The cross-platform version of this design is set out in how API-based email security works without an MX change.
Write "after delivery, by Graph API, no MX change" in the first line of your security review.
Short on time? Watch the explainer, or book a demo.
A Privileged Role Administrator or a Global Administrator approves it, because only those two roles can consent to application permissions7. The app then calls Microsoft Graph with its own identity, without a signed-in user. Microsoft calls application permissions highly privileged, since they let an app access and modify resources with no user present.
Read every permission on the consent screen before anyone clicks Accept, and record who consented and when.
Schedule the consent with one named Global Administrator or Privileged Role Administrator, and keep the screenshot of the consent screen.
Reading needs Mail.Read as an application permission. That permission allows the app to read email in all mailboxes without a signed-in user11. Change notifications for new messages also need Mail.Read12. The delegated version is no substitute. It only subscribes to folders in the signed-in user's own mailbox.
Plan removal as its own step. Microsoft documents a removal route in Graph, the remediate API, which can move to junk, move to deleted items, soft delete, hard delete or move to Inbox15. It sits in the beta version, and Microsoft says use of these APIs in production applications is not supported.
Ask every candidate, in writing, which permission it uses to read, which it uses to remove, and which API carries the removal.
Use RBAC for Applications in Exchange Online. It lets admins grant permissions to an application that independently accesses data in Exchange Online9. That is how a pilot reaches a test group before the whole tenant.
Plan for the delay. Changes to app permissions pass through a cache that takes between 30 minutes and 2 hours to update, depending on the app's recent usage10. The time each stage of a rollout takes is set out in how long API-based email security takes to deploy.
Test the scope with one mailbox inside it and one outside it, 2 hours after each change.
Run the integration in this order, and stop at step 5 if the trial is monitoring only.
A Privileged Role Administrator or Global Administrator grants the application permissions.
The service calls Microsoft Graph with its own identity, with no signed-in user.
The application permission lets it read email across mailboxes.
Limit access with RBAC for Applications, and wait up to 2 hours for the change.
Change notification subscriptions on messages need Mail.Read.
The same Graph access lets the service remove messages it believes malicious or unwanted.
Check which API carries the removal, since the remediate API is beta and not supported in production.
Keep a copy of this list in the change ticket, with the admin and the date beside each step.
Score an MX gateway and an API layer on these rows.
| Criterion | MX-routed gateway | API-based layer | AegisAI |
|---|---|---|---|
| MX record | Points to the provider | Unchanged, since it reads after delivery | No change to mail routing |
| When it acts | Before the mailbox | After delivery to user mailboxes | After delivery |
| Removing delivered mail | Ask the provider | Through the Graph API | Needs write access your admin grants and can revoke |
| Access it holds | Mail in transit | Often full access to mailboxes | Reads through the Microsoft 365 API |
| If the service goes down | Mail must route through it, since MX points to it | Ask the provider | Mail keeps flowing, detection pauses |
| Filtering before delivery | Yes, mail passes it first | No | No edge. It reads mail after delivery |
60-second self-check
Six questions. Nothing is sent anywhere; the result shows on this page.
In the last row the gateway has the edge, because mail reaches it first once the MX record points to it. Score each candidate on all six rows, and see them on your own tenant through the demo page.
AegisAI reads mail through the Microsoft 365 or Google Workspace API after delivery, with no change to mail routing18. Mail keeps flowing if the service is down, and detection pauses until the service returns. Removal needs write access your admin grants and can revoke. Have your admin grant that access when you want removal on, and revoke it the same way.
Illustrative example, figures are fictional. Northgate Dental Group (fictional) runs Microsoft 365 with 640 mailboxes and trials an API-based security app. On Monday its Global Administrator consents to the app and records the screenshot. The team scopes the pilot to 40 mailboxes with RBAC for Applications and tests one mailbox outside the scope 2 hours later. On day 3 a phishing message lands in 12 of the pilot mailboxes at 09:14. The change notification reaches the app, which fetches and judges the message. Removal is not yet granted, so the team reads the verdict and removes the copies by hand. On day 10 the administrator grants write access, and the next copy of the campaign is removed from 9 mailboxes without a ticket.
Copy this sequence into your own pilot plan and set your own mailbox counts.
Track three numbers, each in a place you already have.
Review the three numbers on day 30, and grant write access tenant-wide only if the first one matches.
It is a service that authenticates to the Microsoft Graph API and scans messages after they are delivered to user mailboxes. The same access lets it remove messages it judges malicious or unwanted. Mail routing and MX records stay with Microsoft 365.
No. The service reads mail after delivery through Microsoft Graph. An MX change is the gateway model, where the MX record must point to the third-party provider.
Only a Privileged Role Administrator or a Global Administrator can consent to application permissions. Microsoft calls these permissions highly privileged, because they let an app access and modify resources without a signed-in user.
Yes, with RBAC for Applications in Exchange Online, which grants permissions to an app accessing Exchange Online data on its own. Changes take 30 minutes to 2 hours to apply, so test the scope after that window.
No. Microsoft says use of these APIs in production applications is not supported, and the remediate API sits in the beta version. Ask any candidate which route it uses for removal.
Mail keeps its normal route through Microsoft 365, because the service is not in the delivery path. Ask each candidate what stops during an outage and how it catches up on mail delivered during the gap.
