The Connect security review

Before a firm connects its AI assistant to its Microsoft 365 tenant, someone has to be able to veto it. This page is the review path for that person: the Proxara Connect architecture in assessment order, the limits of the system stated plainly, and direct answers to the questions reviewers ask. Proxara sends this same path as the security review package before the setup call of the evaluation. The device product has its own review path at the security review.

The review path

Read in order. Each step names the question it answers and the document that answers it.

1. What is IT being asked to approve? Proxara Connect for IT. The companion to the consent link: the ten delegated read-only permissions, what the consent screen shows, and how to revoke unilaterally.
2. What is the product? What Proxara Connect is, then What the model sees. The work an employee can ask for, and what does and does not reach the model.
3. What is the architecture? This page, next section, then the Connect chapter of the Security Overview.
4. What data is processed, under what terms? Product Privacy Policy, Data Processing Addendum, and the Sub-processor List, which also maps the two providers in the path that are the firm's own rather than Proxara's.
5. What environment does the firm run in? The private environment. The dedicated, single-tenant AWS environment provisioned per firm.
6. How does access come back out? Offboarding and revocation. Every revocation path, on both the Microsoft side and the Proxara side.
7. What are the terms? Proxara Connect Evaluation Agreement, Master Subscription Agreement, and Service Level Agreement.

The architecture, in review order

One dedicated environment per firm. Retrieval, policy, the stand-in vault, and the record all run in a dedicated, single-tenant AWS environment provisioned for the firm. No shared multi-tenant plane holds a production firm's data, and nothing installs on any device.

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 the 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 runs the same stack with that role left unset.

The closed surface. Under the read consent the assistant is offered three abilities, every one declared read. Behind them sit seven read operations: calendar events, mail search and fetch, Teams message search, file search and fetch, and tasks. Each is bound in code to one delegated permission.

Every retrieval goes to graph.microsoft.com on a fixed list of paths, all GET except two POSTs to Microsoft's own search endpoint. A continuation link pointing elsewhere invalidates the response, and a redirected file download loses the employee's credential before Proxara follows it. No arbitrary-URL surface exists, and no path names another person's account.

Two channels, kept apart. The model-visible channel carries only what firm policy permits: the substance of the work with protected references replaced by consistent stand-ins, plus opaque references carrying no client data. It holds the title, the date, a few labels and the body, capped at roughly seven thousand characters per record, and never the sender, the organizer, the attendees or the recipients.

Before publication Proxara re-reads what the model would receive. If any real name or address from the message envelope survived the substitution, the whole request is stopped and nothing is released.

The clear result renders in a Proxara view inside the conversation, over a separate authenticated fetch from the firm's environment. That fetch runs on a single-use capability lasting at most sixty seconds, accepted from one exact origin only, and only for the employee whose own work produced it.

The vault. Stand-in mappings live in a server-side vault inside the firm's environment, scoped per firm and per piece of work. Each is sealed with AES-256-GCM under a key derived for that firm and that purpose, with the root key held in the firm's own AWS secret store, encrypted at rest under the firm's KMS key. Every sealed value is bound to its firm, its purpose and its exact row, so a mapping moved anywhere else fails to open.

A stand-in reads as [Person_0CE2473EA47B]: one of ten category labels and an opaque suffix, derived by keyed HMAC from the piece of work, an internal random reference for that client, and the category. No name, address or source text is an input.

The same client keeps one stand-in throughout a piece of work and receives an unrelated one next time, so nothing accumulates into a profile. Real values are restored in one place only: the private view the employee opens, assembled inside the firm's environment after re-checking that employee's live connection, identity and policy version.

What is kept, and for how long. Three tables ever hold retrieved content or values derived from it: the working copy prepared for the model, the encrypted private view, and the sealed stand-in mappings. All three expire one hour after the brief is prepared.

Every route refuses expired material whether or not the rows have physically been removed; the physical delete runs at the start of that firm's next request. Withdrawing a person's access, or turning the connection off, deletes their working state outright.

The private view and the mappings each carry their own encryption envelope. The working copy prepared for the model does not, and its protection at rest is the encrypted storage of the firm's own database. There is no mailbox copy anywhere: no sync or delta state exists, and every brief re-reads from Microsoft at that moment.

Credential custody. The Proxara Connect application the firm's administrator consents to is backed by a certificate credential held in Proxara's central custody, never copied into any customer environment, image or configuration. The firm's environment proves the application's identity with a short-lived signed statement minted fresh for every token exchange, so it never holds an application password.

A customer environment holds only its own firm's tokens: the per-employee Microsoft grant tokens, sealed with AES-256-GCM under a key held in that firm's own secret store, bound so a sealed token is unreadable in any other firm's environment or any other row. No central service holds customer Graph tokens. Proxara's shared relay carries only a sealed sign-in receipt, and the proof needed to turn it into a token stays inside the firm's environment.

Tenant binding, and what activation proves. Each firm's activation is bound to its exact Microsoft tenant. Every authenticated request revalidates the employee, the tenant, the grant and the current policy version, re-resolving the person against the firm's published directory record rather than trusting the first sign-in.

A consent alone activates nothing. The activation stays pending until a real employee signs in and Proxara performs one live calendar read with that person's own access, matching the tenant, the directory object, the application and the token. Access lapses on its own at thirty days, and a renewal can only narrow the permissions it holds.

Fail closed, never raw. There is no passthrough mode. If policy, the vault, retrieval or extraction cannot complete, the request returns a bounded, safe error. A failure is never resolved by sending unprotected data onward, and what the assistant is told is thin by design: a prompt to reconnect, or that the brief could not be completed.

The record. Five moments are recorded: the protected brief prepared, the finished analysis attached, a request stopped, a request failed, and the employee opening the private result. Each writes one content-free row inside the firm's own environment, signed as it is created and committed into the firm's per-tenant supervision chain, with the steps of one request hash-chained so a missing or reordered step is visible.

The row holds counts, categories, timestamps and reference codes. No field exists for the words of the question, the text of what was read, a client name, or a stand-in; what the employee asked for is stored only as a one-way fingerprint, and the employee appears as an opaque internal reference.

Revocation, from either side. The firm can restrict, disable or delete the application in its own Entra admin center at any time. Inside Proxara, the firm's owner has one control that turns the connection off for the whole firm: it stops the firm's Microsoft authority, disconnects everyone, erases the stored Microsoft credentials, and deletes working records, mappings and views.

That work is committed in the firm's own environment before any other Proxara service is contacted, so an unreachable Proxara service cannot leave the connection running.

One caveat, covered in Offboarding and revocation. Proxara does not poll Microsoft, so a revocation made in Entra is noticed the next time somebody uses the connector. Until then the console still reads as connected.

Stated plainly

The limits of the system, stated as exactly as the design supports.

• Typed and uploaded content is out of scope. Anything an employee types or uploads directly into an assistant is already visible to that assistant. Connect governs the connected path; Endpoint Protection covers typed text and uploads on managed devices.
• A native connector bypasses Proxara. Only requests reaching the firm's own connector address pass through Proxara. An AI host's own built-in Microsoft connector does not. A firm that wants every connected path governed disables the overlapping native connectors in the host's admin settings, which is the firm's setting to make.
• Reading and acting are two separate consents. The consent in front of the administrator grants delegated reads and nothing else: no write permission is requested, and two independent checks fail the firm's environment if the granted list is anything but those ten. Acting in the firm's Microsoft 365, drafting a reply or creating a task, runs under a separate consent granted the same way, so a read approval never quietly becomes a write approval.
• Connect does not screen for prompt injection. Its checks cover who is asking, what policy applies, and which values must be replaced. None look for instructions hidden inside the material. What bounds the risk is that nothing the model writes reaches a system directly. It returns a typed proposal against a closed vocabulary, so free text never becomes an executed instruction, and every target and every citation in that proposal has to resolve to a stand-in and a source item from that same piece of work, so planted text cannot aim the work at anything outside the evidence set. A proposal whose target is unbound, or whose source has moved since it was read, is refused rather than run. Where the firm's rules require it, a named person approves the resolved target and its sources, and the approval is void if either changes. The write boundary re-checks the employee's permission, the policy version, the stand-in binding and the state of the source before it commits. Injection screening itself belongs to the Endpoint Protection device service.
• A classification step runs on a model Proxara operates. Deciding what must be protected involves passing the retrieved window text to an Anthropic model hosted on AWS Bedrock, invoked with no content logging and no caching. That is a separate step from the assistant the employee is chatting with, which only receives the version with stand-ins.
• Stand-ins are not a universal guarantee. A fact whose substance is unique enough can be identifying even with the names replaced. Where that is unacceptable, firm policy blocks the class outright and states the reason. Protected or blocked are the two ways a request runs today; there is no third mode in which the model reasons over facts held back inside the firm.
• The view runs inside the host's software. The clear view is delivered outside the model-visible result, over a direct authenticated fetch. It still renders inside an application the AI vendor controls, and Proxara does not claim protection against a compromised or instrumented host application.
• Delegated access is the ceiling. Every read carries the signed-in employee's own credential, there is no second credential anywhere in the read path, and the application requests no application-only permission. That bound also makes the firm's existing Microsoft permission hygiene load-bearing: Proxara does not repair over-broad permissions the firm has already granted internally.
• There is no per-person switch inside Proxara. The firm-side control is one owner-only, firm-wide off switch. A leaver is stopped by the firm's ordinary Entra step and Proxara reacts to it, so offboarding is inherited from the process the firm already runs, with no second list to keep in step.
• Claude only. Support for other assistants is not switched on. The data model can record another host, but a session for it does not complete.
• Closing an engagement does not delete the environment. The closing run stops every live authority and closes the firm's file, with the environment and its records left in place. Deleting or transferring that environment is a contractual step under the Data Processing Addendum. The signed audit store is separately write-once with a seven-year retention lock.
• Proxara ships no verifier for the Connect record. The exported file carries the signed bytes, the signatures and the public keys, so a reviewer can check it with their own tools. It carries no transparency-log anchor and no inclusion proofs, and Proxara ships no program that checks it.
• The demonstration runs on a synthetic tenant. The live demonstration uses a stocked, synthetic practice tenant on Proxara's machines. No real client data is involved.

Questions reviewers ask

What does the model actually receive?

The substance of the work firm policy permits, with protected references replaced by stand-ins, plus opaque work references. It never receives the sender, organizer, attendee or recipient lines, and the request is stopped if any real name or address would still be visible. A conversation the AI provider retains is a conversation about stand-ins.

How long is retrieved content kept?

One hour. The working copy prepared for the model, the encrypted private view and the sealed stand-in mappings share that expiry, and all three are deleted at once when a person's access is withdrawn or the connection is turned off. What remains afterwards is the activity record, which holds outcomes and counts and no content.

Where do the Microsoft tokens live?

Sealed and stored only in that firm's dedicated environment, under a key held in that firm's own secret store, bound so a sealed token is unreadable in any other environment or any other row. The application's own certificate credential stays in Proxara's central custody. Neither travels to the AI host, the browser, or logs.

What can Proxara's own staff see?

Operational access to a firm's environment is IAM-scoped and gated by two-factor sign-in and a per-firm external identifier, and it exists only where the firm has asked Proxara to operate that environment. A firm that wants none of it runs the same stack with Proxara's operations role left unset, which removes the access entirely.

Can an instruction hidden in a retrieved message make the connector act?

Not on its own. What comes back from the model is a proposal, not a command: it is typed against a closed vocabulary, and every target and source in it has to be one this piece of work already retrieved, so planted text cannot introduce a client, a recipient or a record that was never in the evidence set. Whether the proposal runs is decided by the firm's rules rather than by the model, and where those rules require approval a named person sees the resolved target and its sources first. Connect performs no injection screening of its own, which is stated as a limit above rather than argued away.

What happens when an employee leaves?

Disabling the account in Entra is the whole step. When Microsoft then refuses to renew that person's credential, Proxara withdraws their access on its own: the connector moves to needs reconnection, the stored credentials are erased, their Proxara tokens are cancelled, and their working records, mappings and private views are deleted. Their history stays on the firm's signed record.

What happens when Microsoft or the AI host has an outage?

The connector degrades safely: requests that cannot complete return a bounded error, partial results are labeled partial, and nothing falls back to raw. Availability commitments and the dependency carve-outs for the AI host and Microsoft are in the Service Level Agreement.

What does an examiner or auditor get?

For each request, one JSON file downloaded from the firm's console, carrying every recorded step, the signature over each step, and the public keys needed to check them. Proxara re-verifies the file before releasing it and refuses to serve one that does not verify. It contains no prompt text, no retrieved content, no client names and no stand-ins.

How is this different from giving the AI assistant a Microsoft connector directly?

A native connector hands retrieved content to the model as-is, ungoverned and unrecorded. Through Proxara, firm policy decides what leaves and in what form, protected references become stand-ins before anything reaches the model, the request is stopped if a real identity would survive, and every request and decision lands on the firm's signed record.