For the Microsoft administrator
The one consent IT grants, exactly what the screen shows, everything IT is not asked to do, where the application appears afterwards, and how to revoke it.
Updated July 2026
The Microsoft side of Proxara Connect is one administrator action: a tenant-wide consent to the Proxara Connect application, granted once at Microsoft's own consent link on login.microsoftonline.com. It asks for ten delegated permissions, seven that read a signed-in employee's own Microsoft 365 content and three standard sign-in permissions, and no application-only permission at all. Consent alone switches nothing on: the connection goes live when a real employee signs in and one live calendar read succeeds with that person's own access.
The one-page version, written to be forwarded to whoever approves, is Proxara Connect for IT.
What IT is not asked to do
| Not asked | What is true instead |
|---|---|
| Install software on a device | Connect is hosted. A connector-only firm never reaches the device steps: no agent package, no device pilot, no app upload. |
| Trust or distribute a certificate | A connector-only environment has no interception certificate. The certificate authority is never created. |
| Deploy an Intune or MDM payload | The Intune push, the MDM artifacts and the Teams package do not run for a connector-only firm. |
| Put a proxy in the path | No device and no proxy sit in the Connect path. Reads go from the environment Proxara provisions for the firm to graph.microsoft.com, and nowhere else. |
| Open an inbound firewall rule | The path runs between the assistant, that environment, and Microsoft's own service. Nothing in it listens on the firm's network. |
| Store a credential | The assistant registers itself: no client ID, secret or token for anyone to copy, hold or rotate. Microsoft token requests use a freshly signed assertion, not a shared secret. |
| Grant an application permission | Every permission requested is delegated. No application-only permission, and no write permission. |
Nothing there is a device change, a network change, or a certificate change, so for a firm whose change-advisory board reviews those categories the Microsoft side of Connect falls outside all of them. It is one approval inside Entra.
One bound a reviewer will ask for: every read Proxara makes carries the signed-in employee's own delegated credential and nothing else. There is no second, more powerful credential in the read path.
What the consent screen shows
The link opens Microsoft's own screen. Its title runs to two lines, "Permissions requested" then "Review for your organization", and there is no checkbox anywhere on it. Consent is organization-wide by construction, and the screen says so: "If you accept, this app will get access to the specified resources for all users in your organization. No one else will be prompted to review these permissions."
The "Consent on behalf of your organization" checkbox some administrators remember belongs to the sign-in consent prompt, which is a different screen.
Expect one bold line partway down: "This application is not published by Microsoft or your organization." That is normal. Microsoft shows it for any application it did not publish and the firm did not register, verified publisher or not.
Under the application name sits the publisher line. A verified publisher renders as a name in blue followed by a solid blue circular badge with a white check, and the word "verified" is never written out. An unverified application renders the literal word "unverified", lowercase and bold, in blue, where the name would be. Proxara applies the same test in reverse, and will not register a firm if Microsoft reports no verified publisher on its own application record.
Cancel is on the left, Accept on the right, and approving is one click. The approval then sits as pending until the first employee signs in and Proxara proves the tenant, the granted permissions, and one real calendar read. A consent granted in the wrong tenant shows as a visible setup state, not a silent gap.
The permissions, as Microsoft renders them
The screen shows Microsoft's display names only. The scope strings appear later, in the Entra admin center.
| What the screen renders | Scope | Why it is requested |
|---|---|---|
| Read user mail | Mail.Read | The mail search and message reads behind a brief |
| Read user calendars | Calendars.Read | Resolving "my next client meeting" to a real meeting |
| Read user chat messages | Chat.Read | Teams conversations the employee is in |
| Read user channel messages | ChannelMessage.Read.All | Team channels the employee belongs to |
| Read all files that user can access | Files.Read.All | OneDrive and SharePoint documents the employee works from |
| Read user's tasks and task lists | Tasks.Read | To Do and Planner items |
| Sign in and read user profile | User.Read | Knowing which employee is asking |
| View users' basic profile | profile | The employee's name, for attribution |
| Sign users in | openid | The standard sign-in permission, required for the connector to start |
| Not rendered as a row | offline_access | Renewal, so the employee does not sign in every time |
ChannelMessage.Read.All is the one Microsoft flags as requiring administrator consent. That single flag forces the administrator path, and it is why an administrator is involved at all.
Ten are requested, but the screen may list eight or nine rows: openid is not normally drawn as its own row, and profile is sometimes folded into User.Read.
Every retrieval under this consent is a GET, apart from two calls to Microsoft's own search endpoint. Drafting mail and creating tasks, where the firm wants them, run under a separate permission expansion and a fresh administrator consent, so a read-only approval cannot quietly become a write approval.
Where the application appears, and how to take it back out
View, filter, and search applications in your organization that are set up to use your Microsoft Entra tenant as their Identity Provider.
The list of applications that are maintained by your organization are in application registrations.
Below is the list of permissions that have been granted for your organization. As an administrator, you can grant permissions to this app on behalf of all users (delegated permissions). You can also grant permissions directly to this app (app permissions). Learn more.
You can review, revoke, and restore permissions. Learn more.
To configure requested permissions for apps you own, use the app registration.
In the Microsoft Entra admin center the path is Entra ID, then Enterprise apps, then All applications.
| To do this | Go here |
|---|---|
| See exactly what is granted | The application's Permissions page, under Security. Each row carries the scope string in its Claim value column, the permission text, its type, and who granted it. |
| Revoke one permission | The row's "..." menu, then Revoke Permission. |
| Restrict who may use it | Properties, set "Assignment required?" to Yes, then assign people under Users and groups. "Remove assignment" takes one person back out. |
| Stop sign-in entirely | Properties, set "Enabled for users to sign-in?" to No. |
| Remove it altogether | Properties, then Delete, then Yes to confirm. |
One portal limitation, worth knowing before it is needed: permissions under that page's User consent tab cannot be revoked from the portal at all, only through the Graph API or PowerShell.
One mechanical note, because a reviewer will find it either way. Proxara does not poll Microsoft: it keeps using a stored access token until that token is within two minutes of expiry, and withdraws a person's access the first time Microsoft refuses a renewal or a read. A change made in Entra therefore takes effect on the next use. The immediate stop is the firm owner's own switch in the Proxara console. Ending access walks every path.
If the firm wants to close user consent as well
Control when end users and group owners are allowed to grant consent to applications, and when they will be required to request administrator review and approval. Allowing users to grant apps access to data helps them acquire useful applications and be productive, but can represent a risk in some situations if it's not monitored and controlled carefully.
A checklist item some firms want, not a requirement. Connect works either way.
In Entra, an administrator controls whether ordinary users may approve OAuth applications for themselves. Left open, an employee can grant an AI tool access to their own mailbox with nobody reviewing it. Closed, only applications an administrator has sanctioned reach Microsoft Graph. So the step is to turn user consent off, then sanction Proxara with the consent above.
- Entra ID, then Enterprise apps, then Consent and permissions, then User consent settings.
- Under "User consent for applications", choose "Do not allow user consent", described on screen as "An administrator will be required for all apps."
- Save, from the command row at the top left of the pane rather than the bottom of the form.
The other two options, verbatim: "Allow user consent for apps from verified publishers, for selected permissions", and "Let Microsoft manage your consent settings (Recommended)", which is the current tenant default.
Closing user consent leaves employees at a dead end unless the request path is on too. The neighbouring Admin consent settings page turns it into a queue with named reviewers, through "Users can request admin consent to apps they are unable to consent to". With it off, an employee who tries an unsanctioned application sees "Need admin approval" and no way forward.
Questions
security@proxara.ai reaches the security team directly. The long form of this page is the Connect security review.