Last updated 13 October 2026 (seventeenth revision).
Defenssive AI Security Manager is a security assessment and monitoring service for Microsoft 365. It reads the security configuration of your Microsoft 365 and Microsoft Entra ID tenant, compares it with the CISA Secure Cloud Business Applications (SCuBA) baselines and with additional checks of our own, and tells you in plain language what to fix first.
This page is for the administrator deciding whether to approve it. It says what the product reads, exactly which permissions it asks for, and what it does not do. It is written from the implementation. Its permission lists, its coverage counts and its main statements about data are held equal to the Terms of service and the Privacy notice by automated tests, so those cannot drift apart unnoticed; the rest of the page is checked by hand when it is written. It describes a product. It is not legal advice.
Already have access? Sign in.
At a glance
- Reads, never writes. The product makes no write calls to your tenant. Two of the permissions it asks for, and both roles, are not read-only by name; the section What it asks for says what keeps our use of them read-only.
- Named baselines. CISA SCuBA, plus additional checks of our own, each labelled with where it comes from.
- Four areas, and Azure and AI on Monitor. Identity, Email, Endpoint and Data, and on the Monitor plan a Cloud area for the Azure subscriptions you choose and an AI area for your Azure AI resources, agents and AI applications.
- Honest about gaps. What it could not read is shown as that. It is never shown as a pass.
What you get
- Ranked findings with evidence. Each finding says what is wrong, why it matters, the configuration we read to reach it, and the steps to resolve it.
- An executive summary for the person who has to decide, and downloadable findings as a CSV file.
- Decisions you can record. Set a finding aside as an accepted risk with a reason and, if you choose, a date after which it returns. Or assign it to a colleague.
- Monitoring, on the Monitor plan. Your tenant is re-assessed on a schedule, with a weekly summary and an email when an assessment records a new or returning finding or cannot complete. Alerts follow assessments, not live changes in Microsoft. Azure is assessed about once a week and whenever you start an assessment. Without the Monitor plan, an assessment runs when you ask for one, and Azure is not assessed.
- Your own AI, if you want it (Monitor plan). Ask your organisation's Azure OpenAI to explain a finding or draft a fix plan. Off unless your workspace owner connects it; findings are sent only on request. A separately enabled, restricted pilot lets an active owner request a review against recorded evidence. It is not live verification and can return Insufficient evidence.
- One workspace for your team. Invite colleagues with a role. Each workspace is isolated from every other.
- A clear record of limits. Every assessment shows which checks ran, which could not run, and which did not apply to your licences.
What it checks
Identity and Email checks draw on the CISA SCuBA baselines, Entra ID above all, with checks drawn from the Exchange Online and Defender baselines, plus some checks of our own. Endpoint and Data checks are our own additional checks and are not counted as SCuBA coverage. Cloud checks are open-source Azure checks, made by assessment software we run on our own server, each with its own result and severity and described in our own plain words; its Defender for Cloud plan checks are combined into one finding per subscription. Each check is labelled with its source.
| Area | Examples of what we look at |
|---|---|
| Identity | Conditional Access policies, multi-factor authentication registration, privileged role holders and Privileged Identity Management, authentication methods, application credentials, password protection and smart lockout, idle session timeout, device join settings and Microsoft Entra LAPS, access reviews of guests and privileged roles |
| Preset security policies, anti-phishing, anti-malware and anti-spam policies, Safe Links and Safe Attachments policies, SPF, DKIM and DMARC, Direct Send, SMTP authentication, automatic forwarding, mailbox auditing, mail flow rules, Safe Attachments for SharePoint, OneDrive and Teams, modern authentication, MailTips, personal accounts and add-ins in Outlook | |
| Endpoint | Defender sensor and antivirus health, known exploitable vulnerabilities, secure-configuration recommendations, Intune device compliance, Intune compliance policies and BitLocker requirement, Windows Update rings, app protection for iOS and Android, Windows BitLocker, antivirus, firewall and Windows LAPS policies, whether Windows compliance uses Defender's device risk |
| Cloud (Monitor plan) | The Azure subscriptions where you give our application the Reader role: storage accounts, networking, virtual machines, SQL, PostgreSQL, MySQL and Cosmos DB databases, Key Vault, App Service, Kubernetes Service, container registries, monitoring and activity log settings, role assignments on the subscription and Microsoft Defender for Cloud, among twenty Azure services. Configuration only, not what your resources hold |
| AI (Monitor plan) | Azure OpenAI and AI Foundry resources: API key sign-in, network access, logging, content filters and Prompt Shields, and AI Foundry hubs. Agents with their own Microsoft Entra identity, and whether Conditional Access applies to them. AI applications left out of multifactor authentication. An inventory of AI applications and agents and what each can reach. Configuration only, never prompts or answers |
| Data | SharePoint and OneDrive settings: external sharing, guest re-sharing, approved domains, legacy authentication, idle session sign-out, OneDrive sync. Microsoft Teams settings: external access to other organisations, personal accounts and trial tenants, email into channels, outside cloud storage, anonymous join and start, the meeting lobby, meeting chat, who can present and take control, reporting suspicious messages. Settings only, not your files, chats or meetings |
Not assessed: Microsoft Purview (data loss prevention, sensitivity labels, retention), Microsoft Sentinel and Power Platform, including Copilot Studio agents' own settings; Azure subscriptions not given the Reader role, and Azure and the AI area on any plan but Monitor. The Data area means only the SharePoint, OneDrive and Teams settings above.
Some checks need a licence your tenant may not hold, such as Microsoft Entra ID P1 or P2, Defender for Endpoint or Defender for Office 365. Where that is the case the check says so.
How it connects
- Sign in. New accounts start with an emailed single-use link. There is no password to create. A workspace owner or administrator can then attach a Microsoft work account in Settings, which is what connects your Microsoft 365 tenant. Your workspace is keyed to your Microsoft Entra tenant ID.
- Approve read access. A workspace owner or administrator starts the connection, and a Global Administrator approves the permissions on Microsoft's own consent screen. That screen lists every permission and names the publisher. Check that both match this page before you approve.
- Assign one role. Exchange Online grants access by role, so a Global Administrator or Privileged Role Administrator also assigns Global Reader (recommended) or Security Reader (narrower) to our application in your tenant, as an Active assignment. Consent alone cannot do this. An assignment with an end date stops the Exchange checks when it ends.
- Run the first assessment. We read your configuration and show what passed, what did not, and what we could not read.
- Optional, on the Monitor plan: choose Azure subscriptions. Someone who can manage access to a subscription assigns Azure's Reader role on it to our application. Settings, under Azure, lists the subscriptions we can see and shows the steps.
About the role. Both roles are read roles, and Microsoft classes both as privileged. Microsoft builds into each the right to configure Service Health, which the product never uses. Security Reader is narrower, but Microsoft does not let it read some Exchange settings, so the email checks that need them are reported as not assessed. Neither role can be limited to part of your tenant.
What it asks for
Access is granted by an administrator through Microsoft's own admin-consent screen. It covers three Microsoft services: Microsoft Graph, Microsoft Defender for Endpoint (which the consent screen may show as WindowsDefenderATP) and Exchange Online. Every Microsoft Graph and Defender permission is read-only. The two Exchange permissions are not read-only by name, so the section after the tables says what keeps our use of them read-only.
If this page and Microsoft's consent screen ever differ, believe the consent screen, and tell us. If
your organisation consented before 7 September 2026, your tenant may still show
SecurityIncident.Read.All, which we no longer request and do not use; an administrator can revoke it.
DeviceManagementConfiguration.Read.All, removed that day too, is requested again for the Intune
configuration checks. DeviceManagementServiceConfig.Read.All was requested on 9 October 2026 and removed
the same day, unused; a tenant that approved it then may still show it, and an administrator can revoke it.
The right-hand column says what we use each permission for. Microsoft's own descriptions of these permissions are broader than our use, and the consent screen shows Microsoft's wording.
Microsoft Graph
Eleven application permissions, all read-only.
| Permission | What we use it for |
|---|---|
Directory.Read.All |
Users, groups, domains, directory roles, licences, the applications in your tenant with the permissions granted to them, and the password protection settings (the custom banned password list and smart lockout) |
Policy.Read.All |
Conditional Access, authentication methods, authorisation and app-management policies, and the Microsoft 365 idle session timeout |
RoleManagement.Read.Directory |
Directory role assignments, including eligible ones held through Privileged Identity Management |
SecurityEvents.Read.All |
Microsoft Secure Score |
AuditLog.Read.All |
Which authentication methods each account has registered |
DeviceManagementManagedDevices.Read.All |
Each enrolled device's name, operating system and Entra device ID, whether it is compliant, whether it is company- or personally owned, how it is managed, and when it last checked in |
SharePointTenantSettings.Read.All |
Your tenant-wide SharePoint and OneDrive settings (the checks use only those about sharing, sign-in and sync) — not your files, and not who has shared what |
DeviceManagementConfiguration.Read.All |
Your Intune compliance policies and device configurations: which exist, what they require, and whether they are assigned |
DeviceManagementApps.Read.All |
Your Intune app protection policies for iOS and Android, and whether they are assigned — not the apps on anyone's device |
Policy.Read.DeviceConfiguration |
Your device registration settings: who can join devices to Microsoft Entra, who becomes a device's local administrator, the device limit per user, and whether Microsoft Entra LAPS is on — not any device's password |
AccessReview.Read.All |
Your access review definitions: which reviews exist, what they cover, how often they recur and whether they apply their decisions — not who was reviewed or what was decided |
Microsoft Defender for Endpoint
Four application permissions, all read-only.
| Permission | What we use it for |
|---|---|
Machine.Read.All |
Your onboarded devices, and the health of their Defender sensor and antivirus |
SecurityRecommendation.Read.All |
Defender's secure-configuration recommendations for those devices |
Vulnerability.Read.All |
Known software vulnerabilities Defender has found on them |
Score.Read.All |
Defender's exposure score for your organisation |
Defender also offers permissions that act on a device: isolate it, scan it, restrict what runs on it, open a live-response session. None of them is requested. The product refuses to use an access token that carries one, even if an administrator granted it.
Exchange Online
Two application permissions. Neither is read-only by name.
| Permission | What we use it for |
|---|---|
Exchange.ManageAsApp |
Reading Exchange Online settings: mailbox auditing, the audit log, SMTP authentication, automatic forwarding, sharing policies, connection filtering, preset security policies, anti-phishing, anti-malware, anti-spam and outbound spam policies, Safe Links and Safe Attachments policies, transport rules, Safe Attachments for SharePoint, OneDrive and Teams, modern authentication, MailTips, Outlook on the web mailbox policies, role assignment policies, the report submission policy (where reported Teams messages go), your accepted domains and DKIM signing |
Exchange.ManageAsAppV2 |
Nothing: Microsoft documents it for its newer Exchange Online Admin API (adminapi/v2.0), which the product does not call |
Two things keep our use of them read-only:
- The role you assign. Our setup asks for Global Reader or Security Reader. The product checks the directory roles it actually holds in your tenant, and reports a High finding against us if any of them is not one of those two. (It does not yet inspect Exchange's own role groups, which are a second way to grant Exchange access; our setup does not ask for one. It does not read roles that are only eligible through Privileged Identity Management, which are not held until activated. If it cannot read the assignments, it says so and does not report a pass.)
- The commands we send. The product sends only a fixed list of read commands, each beginning
Get-, with no parameters. A command that changes anything is not on the list, and the product refuses to send one.
Microsoft Teams
No permission. Microsoft documents that reading Teams settings as an application needs none on its Teams admin service: the directory role you assign (above) decides what the application may do. We read your Teams client settings, meeting policies, messaging policies and external access settings through the service Microsoft's own Teams PowerShell module uses, with a fixed list of four read requests and nothing else. Policy settings only: not chats, meetings, recordings or files. Confirmed with Global Reader; whether Security Reader alone is enough has not yet been confirmed.
Microsoft Azure (Monitor plan)
No permission. Azure grants access by role, per subscription: we read a subscription only where you assign our application Azure's built-in Reader role, and only on the Monitor plan. Reader shows how resources are configured, and Microsoft describes it as allowing no changes. It does not open the contents of storage accounts or databases, or the secrets, keys and certificates in a key vault. The reads are made by open-source software we run on our own server, about once a week and whenever you start an assessment. It does not read Entra ID through Azure. Removing the Reader assignment stops the reads of that subscription.
Your Azure OpenAI (optional, Monitor plan)
No permission. If your workspace owner turns on AI, your organisation assigns the built-in Cognitive Services OpenAI User role, on your own Azure OpenAI resource, to our application. There is no key. Removing the role, or turning AI off in Settings, stops it.
People who sign in to Defenssive itself use the standard sign-in scopes (openid, profile, email, offline_access, User.Read).
What the product does not do
- It makes no change in your tenant, including to the settings it reports on. It sends only read requests. What the roles could technically allow is set out above: the Service Health right, and the Exchange permissions.
- It does not read your content. It asks for no Microsoft Graph permission that reads mailboxes, files, chats or calendars, and to Exchange it sends only the fixed list of settings commands.
- It does not send mail as anyone in your organisation.
- It does not read anyone's password. Microsoft does not expose them and we never receive one.
What we do not promise
- Coverage is partial and stated. The version of CISA's Entra ID baseline we measure against, the one in CISA's ScubaGear repository on 17 September 2026, has 34 policies. We have written a check for 30 of them, and 24 are checked on every assessment. We publish the policies we have not built, and why, in section 3 of the Terms of service.
- A clean result means our checks found nothing, not that nothing is there. We assess the configuration Microsoft exposes to us. We do not test whether a control works, whether it is evaded, or whether something outside our permissions is wrong.
- Where we cannot determine an answer, we say so rather than guess. A check that could not read what it needed reports that it could not run. A policy your licence does not cover reports as not applicable. Neither is counted as a pass.
- Findings can be wrong. They are produced by software reading an API, and both change. We correct errors when we find them.
- It reports; it does not respond. Nothing in the product takes an action against a threat. It is not a replacement for Microsoft's own security tooling, nor for a security team.
- We do not guarantee continuous availability, and an assessment may be delayed by Microsoft's own rate limits.
- We are not certified against any standard, and no audit has been performed.
Your data
- What we store. Findings, the configuration evidence behind each, what your team records, and the account details of the people who sign in. We do not copy your mailboxes, documents or messages.
- How it is protected. The evidence behind each finding, the detail of each assessment, the Azure assessment results and the reports we seal are encrypted before they are written to disk, with a separate key for each workspace, itself wrapped by a key held in Azure Key Vault. The rest, such as email addresses and workspace names, is not encrypted by us. The privacy notice says exactly which.
- Isolation. The database, not only application code, keeps one customer's data from being read under another customer's credentials. Row-level security is enabled and forced on the tables holding your findings, evidence and assessments, and is tested on every change.
- Where. Defenssive's workspace storage, backups and application processing are in Microsoft Azure, East US. Optional Azure OpenAI requests are processed by the service your organisation configured, under your Microsoft agreement. The resource region alone does not establish the inference location: Global and DataZone deployments have different processing boundaries. Microsoft's applicable service terms, deployment type and abuse-monitoring configuration determine its processing and retention. We do not promise zero retention or East US-only inference for your Azure OpenAI. Our email provider, Postmark, processes email in the United States.
- Deletion. An owner can close a workspace in Settings, which stops every assessment and email. Closing a workspace, or withdrawing consent, does not delete data. Deletion is performed on written request, by us. A record that the deletion happened, and some email and sign-in records described in the privacy notice, remain. Copies remain in the backups of the current service for about four months at most. The storage account our earlier pilot environment kept its backups in still exists and is not on that schedule.
- AI. Defenssive does not operate an AI model of its own on your tenant data, and our operator rule keeps AI coding and support tools away from it. Optional Explain and Fix plan requests go to your organisation's configured Azure OpenAI with the existing redaction limitations. The separately enabled recorded-evidence review pilot instead permits only a closed set of structured evidence values and can decline to call the model. No AI answer changes a finding or your tenant. The privacy notice explains the different input policies, retained records and processing boundaries.
- Who else processes it. Microsoft Azure for hosting, Postmark for email and, only while the sign-in check is switched on, Cloudflare Turnstile, a bot-detection check on the sign-in page. The software that makes the Azure assessment runs on our own server; it is not a company processing your data.
The full detail, including retention periods, is in the Privacy notice.
Questions administrators ask
Can you read our email?
The product reads email settings, not messages. It asks for no permission that reads the contents of mailboxes, and it sends only a fixed list of settings commands. The roles you assign can expose email-security metadata such as sender and subject, which is why they are classed as privileged, but the product does not read messages.
Can you change anything in our tenant?
The product makes no write calls. Every Microsoft Graph and Defender permission is read-only. The roles we ask for carry one right to configure Service Health, which the product never uses. We can promise what the product does. We do not say that the roles hold no write-capable action.
How do we remove access?
In two steps. Delete our application under Enterprise applications in the Microsoft Entra admin center, which stops Microsoft issuing us new access tokens for your tenant, and remove the directory role you assigned us. Removing only the role leaves our Graph and Defender permissions in place. A token already issued can keep working until it expires. A workspace owner can also close your workspace in the product's Settings, which stops our reading sooner. Our application stays in your tenant, with the access you granted it, until your administrator removes it. Data already collected stays until deleted on request.
Can we limit the role to part of our tenant?
No. Built-in directory roles cannot be scoped; that is how Microsoft Entra works. If you do not assign either role, the checks that read Exchange Online are reported as not assessed, never as passed.
What if we have no Entra ID P1, P2 or Defender licence?
Checks that need a licence you do not hold report as not applicable or as could not run. Neither is counted as a pass.
Status
Defenssive AI Security Manager is in its pilot phase. Sections 7 to 12 of the Terms of service, covering
fees, liability, warranties, indemnities and governing law, do not set out commercial clauses on this
page. If you need those terms before proceeding, or you need a data processing agreement, ask us at
support@defenssive.com.
Defenssive Cybersecurity LLC provides this service.