Trust Center Overview

Proxara Connect runs inside an accounting or tax firm and touches some of the most sensitive material the firm handles. This page is ordered the way a reviewer works through a vendor, and its rule is simple: every claim ends in a document you can read, a mechanism you can name, or a check you can run yourself.

Two guided paths walk this material in assessment order: the Connect security review, which also states the limits of the system plainly, and IRC § 7216 and the disclosure boundary, the regulatory analysis.

What Proxara Connect is

Proxara Connect connects the systems a firm's work actually lives in, joins the context inside the firm, keeps protected client and tax information there, and lets the AI the firm already uses finish the job.

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 Karbon, Outlook, SharePoint, a CRM where the firm runs one, selected tax systems, and document stores; reconciles the requirements recorded against what actually arrived; separates missing from received-but-unfiled; prepares the follow-up; updates the engagement; and confirms both systems. Nothing installs.

Each system is separately governed: its own credentials, its own approval, its own closed set of registered operations. 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.

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.

The customer-contained plane has 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: network privacy and processing containment are different properties, and this section does not present one as the other. There is no silent fallback between lanes.

What reaches the model, and what never does

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

A verifier 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 cumulative state for that destination is current. Insufficient coverage yields one of six outcomes: stay local, omit the source and record it, ask a clarification, require a fresh destination, refuse the purpose, or block. There is no passthrough mode.

Disclosure is evaluated cumulatively against everything already released into the same external destination, not one prompt in isolation. Where a host cannot attest that a new conversation is isolated, the enclosing session is treated as cumulative, a fresh destination is required, or the work stays local. Proxara cannot erase a model's or a host's memory and does not claim to.

The private workspace

Clear client 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. No clear value enters host tool output, host-visible structured content, host-controlled messaging, the URL, the referrer, client telemetry, or support logs. A host adapter or MCP app may open the workspace and carry model-safe status, never the values.

The workspace is first party rather than embedded for a stated reason: an MCP sandbox protects the host from the app's code and proves nothing about whether the host provider can read what its own runtime renders.

Failure, and truthful completion

A request whose policy, retrieval, classification, or release stage cannot complete returns a bounded, safe error; partial results are labelled partial; nothing falls back to sending unprotected data. A Proxara failure never blocks an employee's ordinary work, and it never resolves itself by leaking.

A provider's success response is not evidence that an effect happened. Durable intent is recorded before any change, execution runs once under the provider's own replay rules, and authoritative provider state is read back and compared with the bound intent. The terminal states stay distinct: 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 and never resends an effect already verified.

The record

Each piece of work records the requesting principal, the approved definition and purpose, which source capabilities were consulted, what was correlated or deliberately kept separate, which claims were released to which destination, what stayed private or was omitted, which target was bound, who confirmed, what the source system confirmed, and what remains unresolved. Rows hold counts, categories, timestamps, and reference codes, never the request text, the material read, a client name, or a stand-in.

Records are canonicalized under RFC 8785, signed as they are written, and hash-chained per firm, so a missing or reordered step is visible. An export carries the verbatim signed bytes, the signatures, and the public keys, so a reviewer can verify it with their own tools. It carries no transparency-log anchor and no inclusion proofs, and Proxara ships no verifier program for it.

The environment: isolation, and control

Every stage runs in a single-tenant environment provisioned for one firm, with its own network, its own KMS keys, its own database, and its own record store. That is isolation, and it is not the same as control.

Control is recorded 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 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 and how each session is authorized; every network route in and out; where local model weights and serving images come from; and how the firm suspends, exports, or removes the system. A dedicated account never stands in for one of those facts.

Where a firm asks Proxara to operate the environment, that access is role-scoped, gated by two-factor sign-in and a per-firm external identifier, and logged. The only stream Proxara receives from an environment is content-free operational telemetry, validated at egress against a fixed schema, carrying no names, no hostnames, and no content, and mirrored to a ledger the firm can read in its console.

The hosted demonstration is a separate, lighter surface on Proxara-operated infrastructure with a synthetic practice tenant. No real client data is involved in a demonstration.

Retention and deletion

There is no standing copy of the firm's systems: content is fetched when asked, and every piece of work re-reads from the source at that moment. Retention is a class rather than one number, and each class names a purpose, an expiry, and an erasure method.

Mappings are durable on purpose: a system whose mappings existed only in memory could not prove or safely repair an effect it had already committed. At the end of an evaluation or a contract that does not convert, the deletion covers retrieved content, working state, the stand-in vault, and grant tokens in one pass, and is certified in writing. Converted deployments carry their record forward unchanged.

The tax rule, in two halves

IRC § 7216 governs both the disclosure of tax return information and its use. The customer-local compilation boundary answers the disclosure half. The use half is answered by purpose-bound policy: a purpose outside the engagement does not compile, and it fails before anything is retrieved.

Consent remains genuinely required where the use leaves tax preparation. Cross-selling from return data, training a general model on client data, and analyzing returns for third-party financial products are use questions, and they arise whether or not anything ever leaves the firm. Proxara enforces the line the firm's counsel draws; it does not draw it, and it makes no claim that a firm is compliant.

The full analysis is at IRC § 7216 and the disclosure boundary. Proxara does not provide tax or legal advice. Firms should confirm the treatment of their own workflows with their counsel.

Sub-processors

Amazon Web Services hosts the dedicated environment and is the primary sub-processor. Two parties in the Connect path are the firm's own rather than Proxara's: the firm's approved model provider, which receives the constructed release package under the firm's own agreement, and the firm's source systems, retrieved from under the firm's own consent. The complete map is maintained with 30 days' change notice on the Sub-processor List.

Framework mapping

Proxara does not certify a firm as compliant and does not enforce a statute. The frameworks below are rules the firm answers to; the record is mapped to them so supervision can be evidenced. Risk is reported as a qualitative band, never a numeric score attached to a named person.

The detail behind each is in the Security Overview and the Data Processing Addendum.

Incident response

Detect, triage, contain, notify, review. Material incidents are notified within 72 hours. For healthcare deployments, breach notification follows the HIPAA standard, up to 60 days per 45 CFR 164.410. Security researchers can report issues to security@proxara.ai under responsible disclosure.

The documents

Every policy, agreement, and reference that governs a deployment lives in this section.

• Policies: Privacy Policy, Product Privacy Policy, Acceptable Use Policy, Cookie Policy.
• Agreements: Terms of Service, Master Subscription Agreement, Proxara Connect Evaluation Agreement, Service Level Agreement.
• Compliance: IRC § 7216 and the disclosure boundary, Data Processing Addendum, Proxara Connect DPIA, HIPAA Business Associate Agreement.
• Reference: Security Overview, Proxara Connect for IT, Client Consent Template, Sub-processor List, and the guided Connect security review.

For product and privacy questions, write to support@proxara.ai. For security and disclosure, write to security@proxara.ai.