What inxo asks for in Microsoft 365

On the consent screen

When an administrator approves inxo, Microsoft's consent prompt lists six permissions in Microsoft's own wording; the identifiers below are the ones shown under Enterprise applications › inxo › Permissions. inxo is not yet a verified publisher, and the prompt says so.

Five of the six reach nothing until a further grant exists or a person signs in. Application.Read.All works as soon as it is approved, on directory records only.

inxo requests no Microsoft Graph mail permission and no organisation-wide Exchange mail permission. If your organisation approved inxo before 5 October 2026, it may still hold User.Read.All, which inxo no longer requests or uses; inxo's checks refuse to run while it is present, so remove it under Enterprise applications › inxo › Permissions.

To read and answer a shared mailbox

Setup asks one of your Exchange administrators to sign in to Microsoft, and creates the following as that administrator, under their own sign-in:

• Once per organisation, Exchange's own record of inxo's application.
• For each mailbox, a management scope that selects only that mailbox — or, if your organisation already has an inclusive scope selecting exactly that mailbox, inxo assigns through it and changes nothing about it — and two Exchange application roles assigned through it: Application Mail.Read, to read the messages in that mailbox, and Application Mail.Send, to send as it.
• Once per organisation, two read-only Exchange roles inxo creates for itself, inxo-read-configuration and inxo-read-recipients, described below.

With the mailbox roles, inxo reads new mail in that mailbox's Inbox, with attachments; reads its Sent Items to confirm what was sent; and, to notice mail moved out of the Inbox while processing was paused, reads the ids and dates of messages in its other folders, not their content. It sends replies, which Exchange saves to Sent Items. It does not change, move or delete messages. It subscribes to Microsoft Graph change notifications on that mailbox's Inbox, so it hears about new mail without polling, and keeps a copy of each message it reads while the mailbox is connected.

Replies go only after a person approves them, unless your account turns on agent auto-send or template acknowledgements — both off by default, and blocked until a separate authorship election is accepted.

Mailboxes connected before 6 October 2026 were given Application Mail.ReadWrite, which also allows changing and deleting messages. inxo never used that. Running setup again adds Mail.Read beside it, and your administrator can then remove the broader role.

The two read-only roles

inxo-read-configuration carries Get-ManagementRoleAssignment,Get-ManagementScope, Get-AdministrativeUnit and Get-OrganizationConfig.inxo-read-recipients carries Get-Recipient and Get-Mailbox. Nothing in either changes anything. They let inxo read what Exchange returns for every recipient in your organisation — names, email addresses, recipient types and, for mailboxes, settings such as forwarding and who may send on its behalf — and your organisation's Exchange role assignments and scopes. They do not let it read mail.

inxo's code uses them to check its own access: which roles it holds, and which mailboxes a scope selects. It reads them for the mailbox being connected, for a bounded preview of what each scope selects, and to pick one other mailbox in your organisation as a test target. inxo keeps that mailbox's address with the connection while it is connected and forgets it on disconnect; in every check it asks to read that mailbox expecting Exchange to refuse, so the denied-access entries in your logs are the check working.

If a role with one of those names already exists, setup reuses it when it carries only those commands, adding any that are missing. If it carries anything else, setup stops without changing it.

The check before a mailbox is switched on

Before a mailbox is switched on, inxo checks the access it actually has — not the access it was meant to get. Its Exchange mail roles must be Mail.Read, or the older Mail.ReadWrite, and Mail.Send — MailboxSettings.Read is also tolerated — each restricted to a scope that selects exactly that mailbox and was made for your inxo account. On the Entra side, inxo's application may hold nothing beyond the permissions listed above on Microsoft Graph, Exchange Online or SharePoint Online. inxo must be able to read the mailbox, and must be refused by a different one. It records what it found as evidence you can see.

It repeats the check every day; access widened between checks is not seen until the next one. If a check conclusively finds wider access, inxo stops sending, drafting, reading new mail and renewing its notification subscription for that mailbox, and resumes when a later check passes; the wider access itself stays until you remove it. If a check cannot read the evidence, it is retried and does not stop the mailbox.

What the check cannot see: a Microsoft Entra directory role, such as Exchange Administrator, assigned to inxo's application. Reading those needs a permission inxo does not request.

The administrator's sign-in

The administrator's sign-in is used for that one setup and is not stored. inxo does not request offline_access, so Microsoft issues no refresh token. Like any Microsoft sign-in it stays valid until it expires — by default between 60 and 90 minutes, which Microsoft does not guarantee — and signing out does not end it sooner. What setup creates is permanent, exactly as if your administrator had created it by hand.

To read documents from SharePoint

Only if you connect SharePoint.

• Your administrator's grant sets the outer limit: the sites inxo can read. Within them, inxo reads only the files and folders a person connects in inxo. It issues read requests only, and does not check whether you granted read or write — grant read.
• Before every read, inxo checks the permissions its application holds, both in the access token it is about to use and in your directory. If it finds anything beyond Sites.Selected and Application.Read.All on Microsoft Graph, or any application permission on the SharePoint API, it refuses to read.
• It does not apply SharePoint's own permissions to individual files, so connect only what you are happy for drafts to draw on. inxo keeps an indexed copy of what it reads; text from it can appear in replies to your customers after review, and passages are sent to inxo's model sub-processors to draft them.

To read knowledge articles from Dynamics 365

Only if you connect Dynamics 365.

• The person connecting signs in once so inxo can list the Dynamics 365 environments they can see. That sign-in is not stored, and inxo does not request offline_access.
• inxo reads published knowledge articles as an application user your Dynamics administrator creates in your environment, with a security role your administrator chooses. inxo's code issues read requests only; it does not check how broad that role is, so grant read access to the Knowledge Article table only. Removing that application user ends inxo's access.

Taking access away

• Disconnecting a mailbox in inxo stops the sync and deletes the mail and drafts inxo holds for it. The Exchange access for that mailbox stays until an administrator removes it. inxo's per-mailbox scopes are named inxo-<connection id>; where your own scope was used, only inxo's assignments are removed. The Console lists per-mailbox access inxo created that is no longer in use, and can remove it with an administrator's sign-in where nothing else depends on it. Exchange's record of inxo's application is never removed by inxo.
• The two read-only roles stay until your administrator removes them, because every inxo connection in your organisation uses them, and inxo never removes them. Removing them while a mailbox is still connected makes that mailbox's next check fail and stops it. When you no longer use inxo, in Exchange Online PowerShell (each assignment's name ends with inxo's service principal object id;Get-ManagementRoleAssignment -Role inxo-read-configuration lists them):

Remove-ManagementRoleAssignment "inxo-read-configuration-<service principal object id>" -Confirm:$false
Remove-ManagementRoleAssignment "inxo-read-recipients-<service principal object id>" -Confirm:$false
Remove-ManagementRole "inxo-read-configuration" -Confirm:$false
Remove-ManagementRole "inxo-read-recipients" -Confirm:$false

• Removing a SharePoint site grant, or the Dynamics 365 application user, ends inxo's access to it.
• Deleting inxo's application from your directory (Enterprise applications) stops inxo obtaining new tokens for your organisation; one already issued stays valid until it expires. It does not remove the Exchange roles, scopes and assignments, the SharePoint site grant or the Dynamics 365 application user — remove those first if you want inxo's Console to do it for you.
• Removing access in Microsoft 365 deletes nothing inxo holds. Disconnecting a mailbox deletes the mail and drafts for it. Knowledge-base copies, including SharePoint and Dynamics 365 text, go when you delete them or with the last mailbox connection for that controller. Audit records are kept for at least a year, and backups roll off in about seven days.