Proxara Connect for IT
The one-page companion to the consent link: the delegated read-only permissions and why each exists, what the admin consent screen shows, where the application appears afterwards, and how to revoke it unilaterally.
Updated July 2026
Proxara Connect for IT
Last updated: July 2026
One page for the administrator who is asked to approve the consent. What Proxara Connect is, exactly what the consent grants, what the screen will show, and how to take it back out. This page is also the first page of the Connect security review.
What is being approved
Proxara Connect joins the firm's AI assistant to the firm's Microsoft 365 tenant through a dedicated environment run for the firm alone. Claude is the assistant it works with today.
An employee asks the assistant to prepare a brief for a specific upcoming meeting. Proxara retrieves what that employee is already permitted to see across mail, calendar, Teams, files and tasks, applies the firm's policy, replaces protected client references with stand-ins before anything reaches the model, and shows the employee the real result in a Proxara view inside the conversation. Nothing installs on any device.
This consent grants reading. Acting in the firm's Microsoft 365, drafting a reply or creating a task, requires a separate consent the firm approves in the same way.
The approval is one tenant-wide administrator consent to the Proxara Connect application, granted once through Microsoft's admin-consent screen. Microsoft's own wording on that screen: "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."
Consent alone switches nothing on. The firm's environment records the approval as pending until a real employee signs in with their own Microsoft account and Proxara performs one live calendar read with that person's own access, confirming the right tenant, the right person and the full permission set. A consent granted in the wrong tenant, or a partial approval, surfaces as a visible setup problem rather than a silent gap.
The one sentence that matters most
Every permission requested is delegated and read-only.
Every read Proxara makes carries the signed-in employee's own credential and nothing else. There is no second, more powerful credential anywhere in the read path, and the application requests no application-only permission at all. Microsoft's own display names carry the same bound: the files entry on the consent screen reads "Read all files that user can access".
The permissions, and why each one
The consent screen is the authoritative list. These are the ten permissions the application requests, with the display name Microsoft renders for each.
| Permission | What the consent screen shows | Why it is requested |
|---|---|---|
| Mail.Read | Read user mail | Client work that starts in the employee's own mailbox |
| Calendars.Read | Read user calendars | Resolving a request to the actual meeting on the employee's calendar |
| Chat.Read | Read user chat messages | Teams conversations the employee is in |
| ChannelMessage.Read.All | Read user channel messages | Team channels the employee already belongs to |
| Files.Read.All | Read all files that user can access | OneDrive and SharePoint documents the employee already works from |
| Tasks.Read | Read user's tasks and task lists | Microsoft To Do and Planner items the employee owns or can see |
| User.Read | Sign in and read user profile | Knowing which employee is asking |
| profile | View users' basic profile | The employee's name, so results are attributed correctly |
| openid | Sign users in | The standard Microsoft sign-in permission |
| offline_access | Not rendered as its own row | So the employee does not sign in again on every request |
ChannelMessage.Read.All is the one permission Microsoft flags as requiring administrator consent. It is the reason the approval has to come from an administrator at all.
Two notes for anyone comparing this table against the live screen. The screen shows Microsoft's display names only; it never prints the raw permission strings. And it may list fewer than ten rows: offline_access does not get a row of its own, openid did not appear as a row in any published Microsoft capture of this screen, and profile can be folded into the User.Read row.
Write permissions (drafting mail, sending mail, creating tasks) are not part of this consent. Drafting and task creation run under a separate, explicit permission expansion with a fresh administrator consent, so a read-only approval can never quietly become a write approval. Two independent checks enforce the boundary: the firm's environment refuses to build, and the setup run refuses to finish, if the permission list is anything other than these ten.
What the consent screen shows
This is Microsoft's tenant-wide admin-consent screen. Its title runs to two lines, "Permissions requested" then "Review for your organization". There is no "Consent on behalf of your organization" checkbox on it. That checkbox belongs to a different Microsoft flow, reached through the ordinary sign-in path.
Three things are worth expecting before they appear.
- The bold warning. "This application is not published by Microsoft or your organization." Microsoft shows this for every third-party application, including ones whose publisher is verified.
- The publisher line. Directly under the application name. A verified publisher renders as the publisher's display name in blue, followed immediately by a solid blue circle holding a white check; the word "verified" is never written out. An application whose publisher is not verified renders the literal lowercase word
unverified, in bold blue, in that same position. - The buttons. Cancel on the left, Accept on the right.
The publisher line is the check worth making, because it is the one thing on the screen this page cannot tell an administrator in advance. If it reads unverified, stop and write to security@proxara.ai before approving.
Where it appears afterwards, and how to remove it
After consent, Proxara Connect appears in the firm's own Entra admin center under Entra ID > Enterprise apps > All applications, like any other application the firm has approved. Opening it gives the firm three controls, usable at any time and without asking Proxara.
- Permissions lists exactly what was granted, one row per permission, with a per-row menu whose single item is "Revoke Permission".
- Users and groups restricts who may use the application, and "Remove assignment" takes an individual back out.
- Properties carries the tenant-wide switches: "Enabled for users to sign-in?" set to No, "Assignment required?" set to Yes, and "Delete" to remove the application's service principal outright.
One honest mechanical note. Revoking in Entra stops Microsoft issuing anything new, but Proxara holds a delegated access token for each connected employee and does not poll Microsoft. It will keep using a stored token, with no call to Microsoft, until that token is within two minutes of its own expiry. The immediate product-side stop is the firm owner's own control in the Proxara console, which turns the connection off for the whole firm: it erases the stored Microsoft credentials, disconnects everyone, and deletes the working records. Ending an evaluation or a contract runs both.
Where the data lives
Retrieval, policy and the stand-in vault run inside a dedicated, single-tenant AWS environment provisioned for the firm. The encryption keys are created in that account, and only the firm's account root can delete or disable them. Where the firm asks Proxara to operate that environment, Proxara's operations role holds use rights on those keys and read access to the firm's secret store, gated by two-factor sign-in and a per-firm external identifier. A firm that wants no Proxara access at all runs the same stack with that role left unset.
Each employee's Microsoft grant tokens live only in that environment. They are sealed with AES-256-GCM under a key held in the firm's own secret store, and bound to that firm, that purpose and that exact database row, so a sealed token is unreadable anywhere else. No central Proxara service holds customer Graph tokens. Microsoft returns each sign-in to a shared Proxara relay, which carries only a sealed receipt; the proof needed to turn that receipt into a token never leaves the firm's environment.
Retrieved content is fetched when asked, held briefly to serve the answer and the employee's private view, then expires. The window is one hour. After that every route refuses it, and the rows are deleted at the start of that firm's next request. They are deleted immediately whenever a person's access is withdrawn or the connection is turned off. What persists is the firm's signed activity record, which holds outcomes, counts and categories and no client content.
The credential behind the Proxara Connect application itself stays in Proxara's central custody and is never placed in any customer environment. The firm's environment proves the application's identity with a short-lived signed statement minted fresh for every exchange, so it never holds an application password.
The full architecture is in the Connect security review and the Security Overview.
Questions
security@proxara.ai reaches the security team directly. The Data Processing Addendum and the Sub-processor List state the processing terms behind this page.