Proxara Connect DPIA
Article 35 assessment for Proxara Connect: retrieval of Microsoft 365 content under delegated permissions, stand-in processing, the server vault, host-visibility and re-identification risks, and the mitigations behind each.
Updated July 2026
Proxara Connect DPIA
Last updated: July 2026
Controller / Processor: Proxara, Inc.
Assessor: Jex Pearce, Founder
This Data Protection Impact Assessment is prepared under Article 35 of the UK GDPR and EU GDPR. It assesses one processing activity: Proxara Connect, the customer-local boundary that lets the AI a firm already uses complete accounting and tax work across Karbon, Microsoft 365 and SharePoint, a CRM where the firm runs one, selected tax systems, and document stores. The archived device agent is a separate activity with its own assessment.
0. How to read this assessment
Four kinds of statement appear below and they are not interchangeable. Unmarked statements in Sections 1 and 4 are technical facts the product enforces in every deployment. Section 2.4 holds deployment assumptions: conditions that must hold for the risk ratings to be valid. Statements named as such are controller decisions, which Proxara represents and enforces but does not make. Section 6 holds questions for counsel, which this document does not settle. Nothing here is a legal conclusion on any firm's behalf, and nothing here is tax advice.
1. Description of Processing
1.1 What Proxara Connect does
The reference activity is the busy-season document chase. A preparer asks what is genuinely still outstanding for one engagement. Inside the firm's own environment, Proxara retrieves what that employee's delegated permissions allow, parses the documents, classifies the material, resolves identity and engagement context, reconciles the requirements recorded in the practice-management system against what arrived by mail and in the document store, and applies the firm's policy.
Any payload reaching an external model is constructed from typed claims the firm's policy admitted. It is not a document with recognized parts removed, and material the system cannot account for is never emitted. The preparer reads the clear result in a first-party Proxara workspace under the firm's own single sign-on. Where the firm enables action features, an approved draft or task is resolved to its exact values only inside the firm's environment, immediately before the firm's own system receives it. Every operation lands on a signed, content-free record.
Four processing lanes exist, and the approved kind of work selects among them: deterministic local processing; a customer-contained model for raw and sensitive context; an approved external model receiving only the constructed release package; and an explicitly authorized raw external route where the firm has separately configured a basis for that exact purpose, processor, data class, and destination. The fourth is never a fallback for a failed compilation, and there is no silent fallback between lanes.
Nothing installs on any device: deployment is one administrator consent granting delegated reads, plus the connector address added in the assistant.
1.2 Deployment model and control
Every deployment runs in a single-tenant environment provisioned for one firm; no shared multi-tenant environment holds customer data.
Isolation is not control. Each deployment separately records which of two modes is active, a firm-owned account with a revocable Proxara deployment role or an explicitly contracted isolated managed account, and in either case records the account owner, who holds root and tenant administration, who owns the keys, what the Proxara role may do and how the firm revokes it, what support access exists, every network path in and out, where local model weights originate, and how the firm exits. This assessment addresses the Proxara-operated mode, in which Proxara is a processor acting on the firm's documented instructions.
1.3 Data subjects
The firm's clients and their related parties are the dominant category: individuals whose personal, financial, and tax information appears in the firm's mail, files, messages, workpapers, and practice-management records. The firm's employees appear through their identity, their requests, and their work content. Other third parties appear inside retrieved content: counterparties, vendors, referred contacts.
1.4 Categories of personal data
| Category | Handling |
|---|---|
| Retrieved source content and parsed document units, which may contain client names, financial detail, identification numbers, and tax return information | Fetched on request under the employee's delegated permissions; parsed and classified inside the firm's environment; encrypted for the class the approved work declares |
| Stand-in mappings | Reversible pseudonymization data in a KMS-encrypted vault in the firm's environment, bound to firm, purpose, and row; never sent to a model, a conversation, or a log |
| Employee identity and grant records | Held in the firm's environment; grant tokens encrypted and row-bound |
| Clear artifacts and private projections | Rendered only in the first-party workspace; encrypted under the artifact's class |
| Release packages and attestations | The claims emitted, their coverage, and the decision; retained under the evidence class |
| The signed operation record | Content-free: no retrieved content, no mappings, no tokens |
1.5 Special category data
Proxara Connect does not seek Article 9 data, but retrieved mailboxes and files can contain anything a client has ever sent the firm. The purpose of the processing is protective: to keep such material from reaching an external model in identifiable form. Firm policy can route designated classes to the customer-contained lane or refuse them outright.
1.6 Recipients
| Recipient | What it receives | Basis |
|---|---|---|
| AWS | Hosts the firm's environment; all raw processing, classification, exact calculation, and customer-contained inference run inside it | Sub-processor (list) |
| The firm's approved external model provider | Only the constructed release package: admitted claims, with protected references as stand-ins | The firm's own provider |
| The firm's own source systems | The source of retrieved content and the destination of approved effects | The firm's own providers |
| Google LLC | Outbound notification email: recipient addresses and message content | Sub-processor |
A managed model endpoint reached over a private network link is a recipient in this table, not part of the firm's environment; network privacy and processing containment are different properties. Proxara does not sell, share, or disclose personal data to any other third party.
2. Necessity and Proportionality
2.1 Lawful basis
The firm, as controller, determines the lawful basis. Typical bases include legitimate interest under Article 6(1)(f) and, for regulated firms, legal obligation under Article 6(1)(c). Proxara processes personal data solely on the firm's documented instructions under the Data Processing Addendum.
2.2 Why the processing is necessary
The useful context for one job is spread across systems no single vendor owns, and the direct route, a native connector inside the AI host, hands retrieved client information to the model as-is, ungoverned and unrecorded. Proxara Connect exists so the connection can be made with the firm's policy in the path.
2.3 Why the processing is proportionate
- Access is bounded by existing permissions. Retrieval is delegated, the consent widens no one's access, and activating a connector is not blanket permission to read that system.
- Purpose is bound before retrieval. A purpose outside the engagement fails to compile before anything is fetched or derived.
- Retrieval is on request. There is no standing copy of the firm's mail, files, or records.
- Construction, not subtraction. The external payload is built from admitted claims; anything unaccounted for never leaves.
- The record is content-free. Supervision is evidenced through decisions, counts, and outcomes.
| Less intrusive alternative | Why insufficient |
|---|---|
| Policy alone, no technical control on the connected path | Unenforceable; a native connector delivers identifiable client data to the model directly |
| Blocking AI-to-system connections | Pushes usage to manual copy-and-paste into chat windows, which is less visible and less protected |
| Redaction of typed prompts only | Does not govern the connected path at all |
2.4 Deployment assumptions
These must hold for the ratings in Section 3 to be valid. Where one does not, the assessment is re-run.
- The environment is single-tenant, and the control facts in Section 1.2 are recorded and accurate.
- Encryption keys are owned by the firm; Proxara holds use rights only.
- The customer-contained plane has no external route and no provider credentials, and its artifacts are pinned by digest.
- The approved external processor is configured with the retention and transport terms the firm accepted.
- Work definitions are activated by the firm after review, under its own counsel-approved purpose policy.
- The firm's existing permissions are appropriate. Proxara does not repair over-broad internal access.
- The firm's employee notice and, where required, client-facing disclosure are in place.
3. Risk Assessment
| Risk | Likelihood | Impact | Overall | Mitigation |
|---|---|---|---|---|
| R1: Unauthorized access to retrieved content or working state | Low | High | Medium | M1, M8, M9 |
| R2: Exposure of the stand-in vault, enabling re-identification | Very Low | High | Low | M1, M4 |
| R3: Re-identification through unique substance, even with names replaced | Medium | Medium | Medium | M3 |
| R4: Host-vendor visibility. The provider retains a conversation about stand-ins | Medium | Medium | Medium | M3, M5 |
| R5: Cumulative identification across a conversation, an agent tree, or days | Medium | High | Medium | M3, M13 |
| R6: Prompt injection in retrieved sources | Medium | High | Medium | M7 |
| R7: Over-broad internal permissions raising the connector's ceiling | Medium | Medium | Medium | M2, M9 |
| R8: Grant token theft | Very Low | High | Low | M6 |
| R9: Cross-tenant confusion between two firms' environments | Very Low | High | Low | M6 |
| R10: Awareness gap, employee or client, where disclosure is required | Medium | Medium | Medium | M11 |
| R11: Erroneous or duplicated effect after an ambiguous provider response | Low | Medium | Low | M7, M9 |
| R12: Prohibited secondary use of return information outside the engagement | Low | High | Medium | M12 |
| R13: Sub-processor breach | Very Low | High | Low | M1, M14 |
Ratings use the scale in the device DPIA: Very Low (negligible), Low (adequately controlled, monitor), Medium (requires active mitigation), High (unacceptable without additional controls).
4. Mitigation Measures
M1: Dedicated environment, administered keys. Every stage runs in a single-tenant environment encrypted under dedicated KMS keys, administered by whoever the deployment record names and assumed here to be the firm (2.4). Proxara's operational access, where the firm asks for it, is IAM-scoped, two-factor gated, logged, and revocable.
M2: Delegated, read-only access. Every permission is delegated and read-only, so the connector can only reach what the signed-in employee can already reach. Consent is inspectable and revocable unilaterally in the firm's own admin center, grants no application-only permission, and acting is a separate consent.
M3: Lanes, not just identifier replacement. Because a sufficiently unique fact can identify its subject even with names replaced, stand-in replacement is not treated as sufficient on its own. Firm policy can route designated classes to the customer-contained lane, where the substance never leaves the environment, or refuse them entirely. This is the primary answer to R3 and part of the answer to R4 and R5.
M4: Vault scoping. Mappings are sealed under a key derived for that firm and purpose and bound to the exact row, so a stand-in copied into an unrelated context resolves to nothing and expired or cross-context stand-ins fail closed. Restoration happens only inside the firm's environment, and mappings appear in no log, record, or model-visible response.
M5: Construction and first-party rendering. The external payload is constructed from admitted claims and structurally verified before release. The clear result renders only in a first-party origin under the firm's own sign-on, bound to the exact recipient and artifact revision, and no clear value enters host tool output, host-visible content, host messaging, the URL, the referrer, telemetry, or support logs. The residual is stated rather than engineered away: an MCP sandbox proves nothing about whether a host provider can read what its own runtime renders, which is why the workspace is first party and not embedded.
M6: Tenant binding and token custody. Each activation is bound to the firm's exact tenant, and every request revalidates employee, tenant, grant, and policy version. Grant tokens are encrypted and row-bound in the firm's environment, no central service holds customer provider tokens, and the application's own credential stays in Proxara's central custody.
M7: Untrusted sources, bounded effects. Retrieved content is data, never instruction authority. A model 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 introduce a client, recipient, or record that was never in the evidence set. Intervention follows consequence rather than every write.
M8: Fail closed. There is no passthrough mode. If policy, the vault, retrieval, extraction, or context resolution cannot complete, the request returns a bounded safe error and partial results are labelled partial.
M9: Content-free record, truthful completion. Every operation records the sources, the decisions, what was released and to which destination, what stayed private, what was committed, and what the source system confirmed. Terminal states stay distinct, a provider success response is never treated as a verified effect, and repair never resends an effect already verified.
M10: Retention by class. Retrieved objects and parsed units end with the work; mappings are held encrypted under an explicit expiry while an effect can still be verified or repaired, then cryptographically erased; clear artifacts end with their own class. Offboarding or termination deletes retrieved content, working state, the vault, and grant tokens, certified in writing.
M11: Notice and consent support. Proxara supplies an employee-facing notice within the Employee Monitoring Disclosure Template and a Client Consent Template. The controller decides and remains responsible; the templates exist so what the firm tells people is accurate.
M12: Purpose authority. Purpose is compiled before retrieval, so a request whose purpose falls outside the engagement does not run, and the system can explain the authorization path without exposing client facts. Where firm policy requires a consent or other authority reference, the work does not run until that reference is present. Proxara enforces the line the firm's counsel draws; it does not draw it.
M13: Cumulative disclosure control. Each release is evaluated against everything already released into the same destination context. 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 erase a model's or a host's memory and does not claim to.
M14: Sub-processor posture. AWS hosts the environment. The firm's model provider and source systems act under the firm's own agreements and are described, with their honest boundaries, in the Sub-processor List.
5. Conclusion and residual risk
This assessment identifies thirteen risks. Most are mitigated to Low or Very Low. Five carry residual Medium risk, stated plainly.
- Re-identification through unique substance (R3). Stand-in replacement is real protection, not anonymization. The customer-contained lane exists precisely because some substance should not leave in any form, and firm policy decides which.
- Host-vendor visibility (R4). Conversations the provider retains are conversations about stand-ins, and the clear result never travels through the host. The host application is still the vendor's software, and Proxara does not claim protection against a compromised or instrumented host runtime.
- Cumulative identification (R5). Accumulation is evaluated and the destination can be rotated, closed, or refused, but no connector can retract what a model or host already holds.
- Prompt injection (R6). Source-planted instructions are an evolving threat across the industry. Treating retrieved content as data, the closed proposal vocabulary, evidence-set binding, and confirmation of consequential effects reduce exposure; the surface changes as the ecosystem does, and the annual review revisits it.
- Awareness (R10) and prohibited secondary use (R12) are controller obligations Proxara can enforce but cannot decide.
Proxara's own assessment, as processor: the processing is necessary and proportionate to the interests pursued, the dominant data subjects are materially better protected with the boundary in the path than without it, and the residual risks are visible, bounded, and honestly stated. The controller's own conclusion is the firm's to reach, on its own facts and with its own advisers. Firms with a Data Protection Officer are encouraged to review this assessment and the Data Processing Addendum as part of vendor assessment.
Next review: July 2027, or upon material change to processing activities.
6. Questions for the firm's counsel or Data Protection Officer
This document does not settle these. They are recorded so nobody assumes they were.
- Whether the firm's chosen lawful basis holds for its own client base and engagement terms.
- Whether the firm's engagement letters and privacy notices already cover AI-assisted processing, or need amendment.
- Which classes of work the firm requires to stay in the customer-contained lane, and on what reasoning.
- Whether an approved external provider's retention terms satisfy the firm's obligations for the categories in Section 1.4.
- How the firm treats a stand-in in its own pseudonymization analysis, given that the mapping is retained inside the firm and is reversible there.
- Where the firm's own uses of client information cross out of the engagement, and what authority it holds for each.
- Whether the firm's choice of model provider engages any transfer mechanism beyond the region in Section 1.2.
7. Contact
Proxara, Inc.
28 Geary St. Suite 650 PMB 5328, San Francisco, CA 94108
Email: support@proxara.ai
Security inquiries: security@proxara.ai