Trust Center Overview

Proxara runs inside a regulated firm and sees some of the most sensitive data the firm handles. This page is ordered the way a reviewer works through a vendor: what the two products are, what runs where, what reaches an AI model and in what form, what happens on failure, what the record holds, and the documents that govern all of it. The rule for the whole section: every claim ends in a document you can read, a mechanism you can name, or a check you can run yourself. The documents are public. Anything gated behind an NDA, such as signed questionnaire responses, is listed by name so you know what exists.

Two guided paths walk this material in assessment order: the Connect security review for the hosted connector, and the device security review for the device agent.

Two products, one foundation

Proxara Connect joins the firm's AI assistant to the firm's Microsoft 365 tenant through a dedicated environment run for the firm alone. An employee asks Claude for work held in the firm's mail, Teams, files, and tasks; Proxara retrieves what that employee's own permissions allow, replaces protected client references with consistent stand-ins before anything reaches the model, and shows the employee the real records in a Proxara view inside the conversation. Nothing installs on any device.

Endpoint Protection is a signed agent on each managed macOS and Windows device, deployed silently through the firm's MDM. It intercepts AI-bound traffic at the network layer, replaces sensitive values before a request leaves the device's traffic path, and signs every event it records.

The two share one dedicated environment, one identity graph, one policy, and one signed record. A firm runs either, or both; adding one to the other is a change of state, not a migration.

What Proxara the company sees, under either product: operational access to the firm's environment is IAM-scoped, MFA-gated, and logged in CloudTrail, and the only stream Proxara receives from the environment is content-free operational telemetry, mirrored to a ledger the firm can read in its console. In a Customer-Managed deployment, Proxara has no access to customer data at all.

Proxara Connect: what reaches the model, and what never does

The model-visible channel carries what firm policy permits: the substance of the work with protected references replaced by consistent stand-ins, so the assistant can reason usefully without learning who anything belongs to. The clear result renders in the Proxara view inside the conversation, delivered over a separate short-lived, authenticated direct fetch from the firm's environment, marked never-to-cache; clear client data is not placed in the model-visible result. The mapping between a stand-in and a real value lives in a KMS-encrypted vault inside the firm's environment and travels on no channel.

Firm policy selects one of three outcomes per class of work. Protected Reasoning is the normal day: the model works on stand-ins. Private Analysis keeps substantive facts inside the firm's environment entirely, with the model receiving only a safe status, which exists because a sufficiently unique fact can be identifying even with the names replaced. Blocked retrieves nothing and states the reason plainly.

Access is bounded twice: every Microsoft permission is delegated and read-only, so the connector can only ever see what the signed-in employee can already see, and the firm's policy then decides what may leave and in what form. The tenant consent is granted once by the firm's administrator, is inspectable in the firm's own Entra admin center, and is revocable unilaterally.

The honest boundaries are stated where reviewers can find them: anything typed or uploaded directly into an AI assistant is already visible to that assistant; a native connector inside the AI host bypasses Proxara unless the firm disables it; and the embedded view, while outside the model-visible result, still renders inside software the AI vendor controls. The Connect security review states each limit plainly.

The device agent: what is decrypted, and what never is

Decryption requires positive evidence that a destination is an AI service. The agent checks every connection against a registry of a thousand-plus AI sites and applications, derived from the Microsoft Purview supported AI list, served from the control plane, refreshed continuously, with an enforced floor of one thousand entries. A match is decrypted, classified, and recorded. Traffic from a known AI application on the device is treated the same way. Everything else is tunnelled through without decryption. A new AI tool is noticed the first time anyone in the fleet touches it.

Hard exclusions run before any AI check. Sign-in and identity providers, banking and payments, healthcare, government, OS-update, and security-tooling destinations are never inspected, and authentication and credential exchanges are never analyzed or modified. Microsoft sign-in and identity traffic is never touched; the device agent does not intercept Microsoft 365 or Teams traffic, and coverage of Microsoft AI surfaces follows the registry. (Proxara Connect's server-side retrieval from the firm's own tenant, described above, is a separate, employee-invoked path, not interception.)

Known certificate-pinned surfaces pass through untouched: the excluded categories above cover the common pinned services, and pinned desktop AI applications are recognized by process and bypassed. Every bypass is reported rather than hidden.

Capture runs through the operating system proxy path on both platforms, scoped to the registry hosts, with the device's prior proxy state snapshotted and restored on removal. That covers browsers and every application that honors the OS proxy. An application that ignores the OS proxy is not silently covered; a deeper transparent-capture layer exists in the product, activates only when its platform signing verification passes, and each device reports which capture mode it is running. The device agent page shows the interception decision live.

Certificates and keys

The firm trusts one Proxara certificate authority per tenant. It is minted server-side during enrollment and delivered to each device over the authenticated enrollment envelope; on the device, the private key is readable only by the system account (file mode 0600, re-asserted on every load). Per-host leaf certificates are minted in memory on demand and never written to disk.

The CA certificate carries X.509 Name Constraints (RFC 5280) that exclude sign-in and identity, banking and payments, healthcare, government, OS-update, and security-tooling domains. A security team can parse the exclusions straight out of the certificate. Two layers enforce that boundary, and it matters which does what: Firefox and other NSS-based software enforce the constraints cryptographically, while macOS does not reliably enforce name constraints on user-added roots, so the operating control there is the agent's runtime interception gate, which applies the same exclusions before any connection is opened. The certificate constraints are defence in depth on top of that gate, and the exclusion list is auditable in both places.

The agent leaves as cleanly as it arrives. One uninstall removes the CA from the OS trust stores (the System keychain and every user's login keychain on macOS; the machine and user certificate stores on Windows), restores the system proxy to its exact prior state, restores MCP client configurations from backups, and removes the service registration and the entire data directory including key material. For pilots, the removal and data-deletion commitment goes in writing before anything installs.

Proxara Connect has its own credential story, stated in the Connect security review: the connector application's certificate credential lives in Proxara's central hardened custody and is never placed in any customer environment, while each firm's environment holds only its own employees' encrypted Microsoft grant tokens.

Failure behavior

The design assumption is that protection degrades sometimes and must say so on the record, and the two products fail in deliberately different directions.

The device agent never blocks. If the CA is not trusted on a device, interception disables entirely and traffic flows natively to the real origin; no Proxara certificate is presented, the employee sees no certificate error, and the operator is alerted. If classification fails or times out, employee traffic passes through unredacted by default and the fail-open is written to the record; the firm can set fail-closed instead, and traffic from automated agents is always held on failure.

Proxara Connect fails closed. There is no passthrough mode on the connected path: a request whose policy, retrieval, protection, or vault stage cannot complete returns a bounded, safe error, partial results are labeled partial, and nothing falls back to sending unprotected data. A Proxara failure never blocks an employee's ordinary web traffic, and it never resolves itself by leaking.

What the supervision layer sees, and what it never sees

For device-side AI-evidenced traffic the layer reads the prompt and the response, the AI surface and the provider it is talking to, the classification of what was found with the policy decision that followed, and the employee identity behind the action. Classification happens inside the firm's environment. The AI provider receives the redacted version.

For connected work, the record is plainer still: which sources a brief drew from, what policy decided, how many protected references were replaced before the model, what action executed and on whose confirmation. The record carries decisions and counts, not the retrieved content, and never the stand-in mappings.

What is kept depends on what was found. When sensitive values are detected device-side, the original text is kept in the firm's environment as signed compliance evidence alongside the redacted version, with a reversible map that lets an authorized reviewer reveal originals on the record. Every reveal is audit-logged, the archive action drops the content and the map, and auto-dismissed events store neither. Clean exchanges are stored content-free, as usage metadata only.

The supervision layer never holds: raw file bytes (only redacted extracted text and a hash of the redacted bytes); raw MCP tool-call payloads (hashes, signatures, and content-free metadata); content from destinations without positive AI evidence; prompts to locally-run models; or copies of the firm's mailboxes and drives, because Proxara Connect fetches on request rather than syncing.

Redaction and stand-in replacement are best-effort with a coverage record. The system seals what it detects and writes a signed record of what it caught, including the moments when it could not check.

The signed record

Every event is signed and hash-chained, so the record is tamper-evident from the moment it is written: device events with a per-device key, connected operations by the workload that performed them, and console actions on a second per-tenant chain. Records are canonicalized under RFC 8785 so there is no ambiguity about what was signed.

On a five-minute cadence, events are batched into an RFC 6962 Merkle tree, the root is signed, and the batch is anchored by default to the public Sigstore Rekor transparency log. The anchor carries the root hash and the anchor public key, never content. Rewriting history after the fact would require forging entries on a log Proxara does not control.

An export produces a self-contained package: the verbatim signed bytes of every event, the public keys, per-event Merkle inclusion proofs, the anchor records, redacted-file manifests that can be re-hashed against the signed record, and a bundled verifier with instructions. It verifies offline, without contacting Proxara.

The environment and isolation

The dedicated, single-tenant AWS environment is the deployment model Proxara provisions for every evaluation, pilot, and customer. Each firm's environment has its own network, its own KMS encryption keys, its own database, and its own audit store; the firm holds the keys and can revoke Proxara's use of them. Everything Proxara Connect holds, retrieved working state, the stand-in vault, grant tokens, and view payloads, is encrypted under those firm-owned keys inside that environment. A Customer-Managed option runs the same stack in the firm's own AWS account, where Proxara has no access to customer data at all.

The hosted trial sandbox and the public demo are a separate, lighter surface: they run on Proxara-operated infrastructure with per-tenant logical isolation, and everything a trial stores is deleted at the end under the purge described below. The Connect demonstration runs on a stocked, synthetic practice tenant; no real client data is involved in a demonstration.

The only stream Proxara the company receives from a firm's environment is content-free operational telemetry: counts, versions, percentiles, and health flags, validated against a fixed schema before they leave, with no names, no hostnames, and no content. Every frame that leaves is mirrored to a Telemetry Ledger the firm can read in its console. What leaves the environment for the model, under Proxara Connect, goes to the firm's own AI assistant in protected form, never to Proxara.

Data retention and deletion

Proxara Connect does not keep copies of the firm's mail and files: it fetches what is needed when asked, protects it, holds working state encrypted only as long as the work requires, and keeps the record of what it did. Stand-in mappings persist in the firm-keyed vault for consistency and are deleted on offboarding or termination.

Device-side reviewable interaction records purge on a rolling window, seven days by default and configurable by the firm. The signed audit chain persists as the compliance record: on customer deployments, signed proofs archive to the firm's own S3 bucket under COMPLIANCE-mode Object Lock with a seven-year default, meeting SEC Rule 17a-4(f), FINRA Rule 4511, and NYDFS 500.6 minimums. Aggregate metrics are retained for ninety days by default.

The on-device identity vault seals each original value under its own AES-256-GCM key; retiring a token destroys the key and makes the original unrecoverable, which supports GDPR Article 17 erasure.

At the end of an evaluation, pilot, or trial that does not convert, the deletion covers the data plane in one pass, including, for Connect, retrieved content, workflow state, the stand-in vault, and grant tokens, and the deletion is certified in writing. Converted deployments carry their record forward unchanged.

Sub-processors

Amazon Web Services hosts the dedicated environment and is the primary sub-processor. Two providers in the Proxara Connect path are the firm's own rather than Proxara's: the firm's AI assistant provider (which receives the stand-in-protected material under the firm's own agreement) and Microsoft (the firm's own tenant, retrieved from under the firm's own consent). The complete map, including the default audit-chain anchoring to Sigstore Rekor and every optional customer-connected channel, is maintained with 30 days' change notice on the Subprocessor List.

Framework mapping

Proxara does not certify a firm as compliant, and it does not enforce a statute. The frameworks below are the 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. Intelligence insights are firm-level, not person-level.

For the detail behind each, read the Security Overview and the Data Processing Addendum.

Incident response

The process is: 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: the Privacy Policy, the Product Privacy Policy, the Acceptable Use Policy, and the Cookie Policy.
• Agreements: the Terms of Service, the Master Subscription Agreement, the Proxara Connect Evaluation Agreement, the Endpoint Protection Pilot Terms, and the Service Level Agreement.
• Compliance: the Data Processing Addendum, the DPIA and the Proxara Connect DPIA, and the HIPAA Business Associate Agreement.
• Reference: the Security Overview, Proxara Connect for IT, the Employee Monitoring Disclosure Template, the Client Consent Template, the Subprocessor List, and the guided review paths: Connect and device.

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