The Connect security review

Before a firm connects AI to its own systems, 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 the same path as the security review package before the setup call of the evaluation.

The review path

Each step names the question it answers.

1. What is IT asked to approve? Proxara Connect for IT
2. What is the product? Introduction and How Proxara works
3. What is the architecture? This page, then the Security Overview
4. What does the tax rule require, and what does the firm still owe? IRC § 7216 and the disclosure boundary
5. What is processed, under what terms? Product Privacy Policy, Data Processing Addendum, Sub-processor List
6. What environment, and who controls it? The private environment
7. How does access come back out? Ending access
8. What are the terms? Evaluation Agreement, Master Subscription Agreement, Service Level Agreement

The architecture, in review order

The reference job throughout is the busy-season document chase: a preparer asks what is genuinely still outstanding for one engagement, and Proxara reconciles the requirements recorded in Karbon against what arrived in Outlook and SharePoint, prepares the follow-up, updates the engagement, and confirms both.

Isolation and control are two different facts. Every stage of that job runs in one environment dedicated to a single firm: retrieval, parsing, classification, local reasoning, the release compiler, the stand-in vault, the private workspace, execution, and the record. No shared plane holds a firm's data, and nothing installs.

Control is separate. 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 same facts.

Isolation never stands in for a row in that table. Where a firm asks Proxara to operate the environment, that access is role-scoped and gated by two-factor sign-in and a per-firm external identifier; a firm that wants none of it leaves the role unset.

The closed surface. The model is offered declared abilities, never a provider client. Behind them sit bounded read operations, each bound in code to one delegated permission and one parameter schema; anything outside the registered set is rejected before a credential is touched. Microsoft retrieval is confined to a fixed list of graph.microsoft.com paths, a continuation link pointing elsewhere invalidates the response, and a redirected download loses the employee's credential first. No arbitrary-URL surface exists, and no path names another person's account.

Each system is separately governed. Karbon, Microsoft 365 and SharePoint, a CRM where the firm runs one, selected tax systems, and document stores each run as their own connection with their own credentials, approval, and closed operation set. Activating a connector is not blanket permission to read that system: authority is assigned to an exact source capability, for one role, in one approved kind of work, and no provider is required by another. Reading two systems never authorizes joining what they hold, and a prohibited connection is never matched at all.

Where each part of the work runs. Raw and sensitive material is parsed, classified, correlated, and reasoned over inside the firm's own environment. Four lanes exist, and the approved kind of work selects among them.

That second lane is unreachable from the internet, holds no provider credentials, and cannot query a source system on its own; its weights, serving image, and templates are versioned and attestable. A managed endpoint reached over a private link stays in the third lane. There is no silent fallback: if the local plane is unavailable, the work waits, returns a local-only result, or stops.

What the model receives is constructed, not filtered. The compiler starts with no output and emits only typed claims the firm's policy admitted for this work, purpose, destination, and recipient. The model does not receive the firm's documents with the sensitive parts removed, and anything the system cannot account for never leaves.

The verifier then proves that every emitted unit maps to an admitted claim, every claim to accounted-for source material, that the package carries only schema fields, that prohibited classes and clear mappings are absent, and that the destination's cumulative state is current. A residual scan of the finished envelope is one of those checks, never the mechanism. Insufficient coverage has six honest outcomes: stay local, omit the source and record it, clarify, rotate the destination, refuse the purpose, or block. There is no passthrough mode.

The clear artifact is first party. Clear names, exact figures, document previews, recipients, and action targets render only in a first-party, customer-authorized origin under the firm's own single sign-on, bound to the exact recipient and artifact revision. Every read and edit recompiles that authority against live employee, work, purpose, and policy state, so holding a URL is not authorization. No clear value enters host tool output, host-visible content, host messaging, the URL, the referrer, client telemetry, or support logs. A host adapter may open the workspace and carry model-safe status, never the values.

The vault. Stand-in mappings live in a server-side vault inside the firm's environment, sealed with AES-256-GCM under a key derived for that firm and purpose and bound to the exact row, so a mapping moved anywhere else fails to open. The external gateway holds no reverse lookup. A stand-in reads as [Person_0CE2473EA47B]: a category label and an opaque suffix derived by keyed HMAC, with no name, address, or source text as an input.

A client keeps one stand-in for as long as the authorized work and its destination require, so multi-step work stays coherent, and it rotates when the work, purpose, or destination changes. Nothing can be assembled across tasks or days. A new stand-in on every prompt is not the design: it would break the work without erasing anything already in the conversation.

What is kept, why, and how it ends. Retention is a class, not one number.

Mappings are durable on purpose: a system whose mappings existed only in RAM could not prove or safely repair an effect it had already committed. Expiry removes external continuity without destroying the internal history needed to prove and repair a real action. Where a single number is quoted for everything, it describes the public demonstration, whose guest sessions are hour-ephemeral. No mailbox or drive copy exists.

Credential custody and tenant binding. The application the administrator consents to is backed by a certificate credential held in Proxara's central custody, never copied into a customer environment or image. The firm's environment proves the application's identity with a short-lived signed statement minted fresh for every token exchange, and holds only its own firm's tokens, sealed under a key in that firm's own secret store and bound so a sealed token is unreadable elsewhere. No central service holds customer source tokens.

Each activation is bound to the firm's exact source tenant, and every request revalidates the employee, tenant, grant, and policy version against the firm's published directory record rather than the first sign-in. A consent alone activates nothing: activation stays pending until a real employee signs in and Proxara performs one live read with that person's access. Authority expires on the schedule the firm sets, and a renewal can only narrow what it holds.

Completion is a verified state, not a response code. Before any change Proxara records the exact intent durably, executes once under that provider's replay rules, then reads authoritative provider state back and compares it with the bound intent. The outcomes stay distinct and are never collapsed: completed and verified, completed with omissions, partial, clarification required, confirmation required, repair required, blocked, cancelled, failed. Repair works only on what is absent or mismatched, so a chase email that went out is never resent because the Karbon update behind it failed.

The record. Each request writes content-free rows inside the firm's own environment: the work admitted and under which purpose, the sources consulted, what was released and to which destination, what stayed private or was omitted, which target was bound, who confirmed, what the source system confirmed, and what remains unresolved. Every row is signed as it is written and hash-chained, so a missing or reordered step is visible. Rows hold counts, categories, timestamps, and reference codes, never the request text, the material read, a client name, or a stand-in.

Revocation, from either side. The firm can restrict, disable, or delete the application in its own administration console at any time. Inside Proxara, the firm's owner has one control that turns the connection off firm-wide: it stops the firm's source authority, disconnects everyone, erases the stored credentials, and deletes working records, mappings, and views. That work commits 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 Ending access: Proxara does not poll the source provider, so a revocation made there is noticed the next time somebody uses the connector, and until then the console still reads as connected.

Stated plainly

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

• Typed and pasted content is out of scope. Connect governs what AI reads out of the firm's systems. Anything an employee types or uploads directly into an assistant is already visible to that assistant, and Connect never sees it.
• 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. Disabling the overlapping native connectors is the firm's own setting to make.
• Reading and acting are two separate consents. The administrator's consent grants delegated reads and nothing else, and two independent checks fail the environment if the granted set is anything other than the reviewed one. Acting runs under a separate consent granted the same way, so a read approval never quietly becomes a write approval.
• Customer-contained is a containment claim, not a network claim. Raw and sensitive material is classified and reasoned over on a plane with no external route, no provider credentials, and no independent access to a source system. A managed model endpoint reached over a private network link is still a managed external processor, and Proxara does not present network privacy as containment.
• The design does not depend on catching a malicious sentence. Detection adds defense; it does not carry the claim. Retrieved content is data, never instruction authority, and nothing the model writes reaches a system directly: it returns a typed proposal against a closed vocabulary, and every target and citation must resolve to a stand-in and a source item from that same piece of work, so planted text cannot aim the work outside the evidence set. A proposal whose target is unbound, or whose source has moved since it was read, is refused rather than run, and where the firm's rules require it a named person approves the resolved target and its sources, with the approval void if either changes.
• 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 either blocks the class outright with the reason stated, or keeps the work inside the firm entirely, so only the finished result reaches the employee's private view.
• Disclosure accumulates, and a connector cannot erase what it does not control. Each release is evaluated against everything already released into that same external destination, not against one prompt in isolation. Where a host cannot attest that a new conversation is isolated, the enclosing session is treated as cumulative, a fresh protected destination is required, or the work stays local. Proxara cannot delete a model's or a host's memory, and does not claim to.
• Disclosure is only half of the tax rule. A purpose outside the engagement does not compile, and it fails before anything is retrieved. That is the half a boundary can answer. Using return information to build a cross-sell list, to train a general model, or to assess a client for a third-party financial product is a use question, and consent is genuinely still required for those, whether or not anything leaves the firm. Proxara enforces the line the firm's counsel draws; it does not move it.
• MCP sandboxing is not a host-confidentiality proof. An MCP app's sandbox protects the host from the app's code. No vendor guarantees that its own runtime cannot read what that surface renders. That is why clear values render in a first-party origin under the firm's sign-in, and why a host adapter receives only model-safe status.
• Delegated access is the ceiling. Every read carries the signed-in employee's own credential, there is no second credential in the read path, and the application requests no application-only permission. That bound makes the firm's permission hygiene load-bearing: Proxara does not repair over-broad access the firm 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 directory step: when the provider then refuses to renew that credential, Proxara withdraws access on its own, erases the stored credentials, cancels the tokens, and deletes that person's working records, mappings, and views. Offboarding is inherited from the process the firm already runs, with no second list to keep in step.
• The same product from every supported surface. Claude, ChatGPT, Microsoft 365 Copilot, a first-party Proxara workspace, and an agent the firm builds against the versioned Work API all reach the same authority and execution boundary, under the same policy, identity checks, and record. A host outside the supported set does not complete a session.
• Closing an engagement does not delete the environment. The closing run stops every live authority and closes the firm's file, leaving the environment and its records in place. Deleting or transferring that environment is a contractual step under the Data Processing Addendum.
• 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.
• The demonstration runs on a synthetic tenant. It uses a stocked, synthetic practice tenant on Proxara's machines. No real client data is involved, and nothing in it is evidence about a live provider account.

Proxara does not provide tax or legal advice. Firms should confirm the treatment of their own workflows with their counsel.

Questions reviewers ask

What happens when a source system or the AI host is unavailable? The work degrades honestly. What can be read is used, the missing source is named, the conclusion that cannot yet be drawn is stated as such, and a private draft is still prepared where one is useful. Nothing falls back to raw. Carve-outs are in the Service Level Agreement.

What does an examiner or auditor get? For each request, one JSON file from the firm's console carrying every recorded step, its signature, 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.

How is this different from a native connector? A native connector hands retrieved content to the model as-is, ungoverned and unrecorded. Through Proxara the purpose is bound first, the payload is constructed from admitted claims, the clear result returns only to the employee's first-party workspace, and every decision and effect lands on the signed record.