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 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 step one of the Connect security review.
What is being approved
Proxara Connect joins the AI the firm already uses to the firm's own systems, through an environment run for that firm alone. It works the same from Claude, ChatGPT, Microsoft 365 Copilot, and an agent the firm runs itself. This page covers the Microsoft consent; Karbon, a CRM, selected tax systems, and document stores are each a separate approval on their own schedule.
The reference job is the busy-season document chase. A preparer asks what is genuinely still outstanding for one engagement. Proxara reads what that employee is already permitted to see across mail, calendar, Teams, files, and tasks, reconciles it against the requirements recorded in the practice-management system, keeps the client's identity and the exact figures inside the firm, and shows the preparer the real result in a first-party Proxara workspace under the firm's own sign-in. Nothing installs on any device.
This consent grants reading. Acting in Microsoft 365, drafting a reply or updating a task, requires a separate consent approved 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 there: "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 approval stays pending until a real employee signs in with their own Microsoft account and Proxara performs one live calendar read with that person's access, confirming the tenant, the 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 carries the signed-in employee's own credential and nothing else. There is no second, more powerful credential 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 reads "Read all files that user can access".
The permissions, and why each one
The consent screen is the authoritative list. This is the reviewed read set 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 evidence that arrives in the employee's own mailbox |
| Calendars.Read | Read user calendars | Resolving a request to the right engagement and deadline |
| 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. It shows Microsoft's display names only, never the raw permission strings, and it may render fewer rows than the table: offline_access gets no row of its own, openid did not appear as a row in any published Microsoft capture, and profile can be folded into the User.Read row.
Write permissions are not part of this consent. Drafting and task creation run under a separate permission expansion with a fresh administrator consent, so a read 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 granted set is anything other than the reviewed one above.
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 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 approved application. Opening it gives the firm three controls, usable at any time 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 control in the Proxara console, which turns the connection off firm-wide: it erases the stored Microsoft credentials, disconnects everyone, and deletes the working records. Ending an evaluation or a contract runs both.
Where the work runs, and who controls it
Retrieval, document parsing, classification, local reasoning, the release compiler, the stand-in vault, the private workspace, and the record all run inside one environment dedicated to this firm. That is isolation, and it is not the same as control.
Control is stated separately. Every deployment names which of two modes is active, a firm-owned account with a revocable Proxara deployment role or an explicitly contracted isolated managed account, and either way writes down the account owner, who holds root and tenant administration, who owns the keys, what the Proxara role may do and how it is revoked, what support access exists, every network route in and out, where local model weights come from, and how the firm exits. The private environment holds that record.
Each employee's Microsoft grant tokens live only in that environment, sealed and bound so a token is unreadable anywhere else. No central Proxara service holds customer Graph tokens, and the credential behind the application itself stays in Proxara's central custody, never in a customer environment.
Retrieved content is fetched when asked, never synced, so no mailbox or drive copy exists and each piece of work re-reads from Microsoft at that moment. Retention is set per class rather than by one number: retrieved objects and parsed document units end with the work; stand-in mappings are held encrypted, with an explicit expiry, for as long as an effect can still be verified or repaired, then cryptographically erased; the clear artifact ends with its own class. All of it is deleted at once when a person's access is withdrawn or the connection is turned off. What persists is the firm's signed record: outcomes, counts, and categories, and no client content.
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.