Security Overview

Last updated: July 2026

This document describes the security architecture, controls, and practices for the Proxara platform: Proxara Connect, the hosted connector that joins the customer's AI assistant to the customer's Microsoft 365 tenant through the customer's dedicated environment, and Endpoint Protection, the device agent. It is intended for customer security teams, compliance officers, and third-party assessors conducting vendor due diligence.

---

1. Architecture

1.1 Deployment Model

By default, Proxara provisions and manages a dedicated, single-tenant AWS account for each customer. There is no shared multi-tenant environment; each deployment has its own VPC, encryption keys, database, and audit store. Customer's IT team is not required to set up or maintain any infrastructure. Customer receives read-only access to the environment, and all data within it belongs to the customer.

A Customer-Managed deployment option is available for organizations that prefer to operate the infrastructure themselves within their own AWS account. In that configuration, Proxara has no access to customer data at rest.

The hosted trial sandbox and public demo are separate from this model: they run on Proxara-operated infrastructure with per-tenant logical isolation, and all trial data is deleted at the end of the trial.

The agent reaches employee laptops through the firm's MDM (Jamf, Intune, Kandji, and compatible platforms). Employees install nothing themselves.

1.2 Core Components

1.3 Proxara Connect: The Hosted Connector

Proxara Connect adds a connector runtime to the same dedicated environment; nothing installs on any device. The security-relevant architecture, stated in review order:

• Access model. One tenant-wide administrator consent to the Proxara Connect application grants delegated, read-only Microsoft permissions: the connector can only ever access what each signed-in employee can already access. The connector reads today; drafting and task creation arrive as a separate, explicit permission expansion with a fresh administrator consent. The application appears in the customer's own Entra admin center under Enterprise applications, where the customer can inspect, restrict, or revoke it unilaterally.
• Two channels, kept apart. The model-visible channel carries only policy-approved material: the substance of the work with protected references replaced by consistent stand-ins, plus opaque work references. The clear result renders in a Proxara view inside the conversation, delivered over a separate short-lived, authenticated direct HTTPS fetch from the customer's environment, with caching disallowed. Clear client data is not placed in the model-visible result. The view still renders inside software the AI vendor controls, and Proxara does not claim protection against a compromised or instrumented host application. Two modes operate today: protected reasoning, in which the model works on stand-ins and never receives the identities behind them, and blocked, in which a class of information does not go out in any form and the reason is stated plainly.
• The server vault. Stand-in mappings live in an encrypted vault inside the customer's environment, scoped to the customer and to one unit of work, and they expire with that work. Unknown, expired, or cross-context stand-ins fail closed. An original value is restored in one place only: the private view the employee opens inside the conversation, resolved inside the customer's environment after the employee's live connection, identity, and the exact policy version are re-checked. Mappings appear in no log, no model response, and no record.
• Credential custody. The Proxara Connect application is backed by a certificate credential held in Proxara's central, hardened custody. It is never copied into any customer environment, image, or configuration; customer workloads obtain only short-lived, tenant-bound assertions from a narrow central signing service that accepts no caller-supplied claims. Each customer's environment holds only its own Microsoft grant tokens, encrypted at rest inside that environment; no central Proxara service holds customer Graph tokens.
• Tenant binding. Every customer activation is bound to its exact Microsoft tenant, and every request revalidates the employee, tenant, grant, and current policy. Tokens, codes, and references from one customer's environment fail closed in another's. Consent alone activates nothing; activation completes when a real employee sign-in proves the exact tenant and granted permissions.
• Egress restrictions. The connector's outbound traffic from the customer's environment is restricted to the reviewed Microsoft endpoints and the customer's AI-host path; there is no arbitrary URL fetch and no open Graph proxy. Unknown operations are denied.
• Fail closed. There is no passthrough mode. A request that cannot complete its policy, vault, retrieval, or extraction stages returns a bounded safe error; it never falls back to sending unprotected data, and partial results are labeled partial.
• Revocation. The customer can revoke on the Microsoft side at any time (with the honest caveat that an already-issued access token can remain valid until Microsoft expires it), and Proxara-side disablement stops the connector immediately, revokes grants, and clears usable token, workflow, and view state.

The reviewer-ordered walk-through of this architecture, with the stated limits, is The Connect security review.

1.4 What the Device Agent Intercepts

Proxara intercepts interactions with external AI assistants and AI features, including ChatGPT, Claude, Google Gemini, Perplexity, DeepSeek, Grok, Azure OpenAI, Amazon Bedrock, and Google Vertex AI, along with the AI features in the firm's connected business applications. Its embedded gateway brokers Model Context Protocol (MCP) tool calls from the clients it can re-point, and inventories the rest.

Microsoft sign-in and identity traffic is never touched; coverage of Microsoft AI surfaces follows the AI-host registry. Sign-in pages and traffic to banking, healthcare, and government services are never intercepted: those categories sit on the agent's runtime never-inspect list, which runs before any AI check, and are also excluded in the CA's name constraints (Section 4.4).

1.5 Never-Block Design (Device Agent)

If the agent's root CA is not OS-trusted (for example, if a device is removed from MDM before the profile is applied), the agent passes traffic straight through to the real origin. No Proxara certificate is presented, so the employee never sees a certificate error. If trust is lost at runtime, interception turns off automatically and the operator is alerted. Sites keep working in all cases.

1.6 Optional: Self-Hosted Inference

For deployments requiring that inference never touch a managed AI service, Proxara can provision a self-hosted classification model inside the dedicated environment as an alternative to AWS Bedrock.

---

2. Data Protection

2.1 Encryption in Transit

2.2 Encryption at Rest

All storage in the customer's dedicated AWS account is encrypted using AWS KMS customer master keys (CMKs) owned by the customer. The customer can revoke Proxara's access to those keys at any time.

Compute runs as ECS Fargate tasks; there are no long-lived compute nodes holding customer data.

2.3 Key Management

Proxara's deployment templates provision dedicated AWS KMS keys within the customer's dedicated account for:

• Database encryption
• Audit log encryption and signing
• General-purpose encryption (secrets and supporting storage)

The customer owns all KMS keys. Proxara has use-only rights and cannot delete, disable, or modify key policies. Full administrative control can be transferred to the customer upon request or at termination.

2.4 On-Device Identity Vault (Endpoint Protection)

The device agent maintains an on-device encrypted vault. Each original sensitive value is sealed under its own AES-256-GCM key (HKDF-derived). Retiring a token destroys its key, making the original value genuinely unrecoverable, including from any backup. This mechanism supports GDPR Art. 17 crypto-shredding, is initiated by the compliance team, and is audit-logged.

2.5 Server Vault (Proxara Connect)

The Proxara Connect stand-in vault runs server-side inside the customer's dedicated environment, encrypted at rest, with the scoping, fail-closed rehydration, and restoration boundary described in Section 1.3. Workflow state, view payloads, and Microsoft grant tokens are encrypted inside that same environment. Mappings expire with the unit of work they belong to, and deleting the vault at offboarding or termination removes every reversible mapping.

---

3. Network Isolation

3.1 VPC Architecture

The service runs within a dedicated VPC with:

• Private subnets for compute (Classification API, console) and database (RDS)
• Public subnets only for NAT gateway and Application Load Balancer
• Security groups restricting inbound traffic to required ports (HTTPS from the device proxy, dashboard access)
• No direct inbound internet access to private compute or database resources

3.2 AWS Bedrock Connectivity

Classification calls run against Amazon Bedrock within the customer's own dedicated AWS account, over TLS via the AWS SDK. Bedrock does not store inputs or outputs and does not use them for model training.

3.3 Data Residency

Customer data is processed and stored within the dedicated cloud environment. Proxara does not operate any shared data processing servers, data lakes, or middleware outside the customer's dedicated account. What leaves the environment goes to parties the customer chose: under Proxara Connect, policy-approved material with protected references replaced by stand-ins goes to the customer's own AI assistant, and under Endpoint Protection, the redacted request continues to the AI provider the employee was already using. Nothing of the customer's content goes to Proxara.

3.4 Fleet Operations Telemetry

To keep each dedicated environment healthy and supported, Proxara receives a stream of content-free operational telemetry from the environment: schema-bound health, availability, and usage counters, for example service status, protection-coverage counts, error-template counts, and resource utilization. This is the only data that leaves the environment for Proxara the company. (Under Proxara Connect, the policy-approved, stand-in-protected material that leaves the environment goes to the customer's own AI assistant; it does not go to Proxara.) Every telemetry payload is validated at egress against a fixed schema and a deny-pattern filter, carries no free text, and contains no customer content and no personal data; it identifies the environment, not any individual. The firm can review every item Proxara receives from its environment in the Telemetry Ledger inside the console.

---

4. Access Controls

4.1 Authentication

4.2 Authorization

The governance console implements role-based access control (RBAC):

• Compliance reviewers can view flagged events, add notes, change status (pending/reviewed/escalated/dismissed), and export reports.
• Administrators can manage users, configure industry profiles, and adjust retention settings.
• All actions in the console are logged with the reviewer's identity and timestamp.

4.3 Operational Access (Proxara-Managed Deployments)

For Proxara-Managed deployments, Proxara personnel access the dedicated cloud account via:

• IAM roles with least-privilege policies
• SCP-protected administrative actions
• Access logs maintained in AWS CloudTrail
• MFA required for all administrative access
• Customer receives read-only access; full administrative control can be transferred to customer upon request or at termination

4.4 HTTP Device Proxy Security

4.5 Rate Limiting

The Classification API enforces per-client rate limiting on all hot-path endpoints (analysis, redaction, ingestion, metrics). Limits are set at 120 requests per minute with a 30-request burst window per 5 seconds. Clients exceeding the limit receive HTTP 429 responses with Retry-After headers.

---

5. Audit Logging

5.1 Interaction Audit Trail

Every intercepted interaction generates a signed audit record containing:

• Classification result (severity, risk category, data types detected)
• For flagged interactions: full prompt and response text (held temporarily for compliance officer review)
• Employee identifier, device identifier, AI provider, timestamp
• For uploaded files: redacted text and a hash of the redacted bytes (raw file bytes are never stored)
• Regulatory control tags

Flagged interaction content (prompts, responses, file text) is purged once the compliance officer archives or dismisses the event, or automatically after 7 days as a fallback. After purge, only the supervision audit log entries and file metadata are retained.

5.2 Cryptographic Audit Chain

Every interaction record and every compliance action is canonicalized (RFC 8785 JCS), signed with Ed25519, and hash-chained, per device (interaction leg) and per tenant (supervision leg).

• Encoding. Canonical JSON (RFC 8785 JCS), with CBOR for MCP events (RFC 8949). Deterministic byte representation eliminates ambiguity over what was signed.
• Signature. Ed25519, signed per event.
• Per-tenant hash chain. Each event carries the SHA-256 of the previous event for the same tenant. Tampering at any link breaks the chain and is detected by verification.
• Five-minute Merkle batches. Recent events are Merkle-rooted on a five-minute cadence, producing per-event inclusion proofs.
• Public-internet anchoring (on by default). Each batch root is anchored by default to Sigstore Rekor, a transparency log operated under the Linux Foundation. The anchor is a signed statement carrying the Merkle root hash and the anchor public key; no event content, device identifier, or tenant identifier leaves the deployment. If Rekor is unreachable, the batch anchor is still recorded locally and the chain continues. After-the-fact tampering would require forging entries on a log Proxara does not control.
• Offline verifier. The bundled proxara-audit-verify CLI confirms signatures, chain continuity, Merkle inclusion proofs, and (where a public-log anchor exists) the Rekor entry. It runs without contacting any Proxara service. Exit code zero means everything checks out.
• Immutable archive. Audit proofs are archived to S3 in COMPLIANCE Object Lock mode for 7 years, meeting the minimums of SEC Rule 17a-4(f), FINRA 4511, and NYDFS 500.6. Proxara's role has no DeleteObject permission on this bucket.

5.3 Immutable Supervision Audit Log

All compliance reviewer actions are recorded in a dedicated append-only audit log table. Entries are never updated or deleted. Each entry contains:

• The event identifier
• The action taken (status change, feedback, note added, event creation)
• The actor who performed the action (reviewer email or system identifier)
• A UTC timestamp
• Action-specific details (such as new status value or note text)

This log carries metadata only; it does not contain the original prompt or response content. It provides the evidence trail regulators require when confirming that supervision was active.

5.4 Data Retention

Proxara operates as a real-time processing and supervision layer, not a long-term data store.

After the retention window, content is purged automatically. Only supervision audit log entries remain.

5.5 Compliance Archive Integration

Proxara is a processing layer, not the system of record. The firm's existing compliance archive (such as Smarsh, Global Relay, or equivalent) remains the official record for regulatory recordkeeping (SEC Rule 17a-4, FINRA supervision). The service can be configured to forward interaction records to that archive; where the integration is enabled, the archive provider's own agreement and retention policy govern those records.

---

6. Data Minimization

The service is designed to minimize data exposure.

---

7. Vulnerability Management

7.1 Dependency Management

• Application dependencies are managed via pip (Python), npm (JavaScript/TypeScript), and cargo (Rust, for the HTTP device proxy and the MCP gateway).
• Dependencies are reviewed and updated on a regular basis.
• Rust dependencies are gated by cargo deny in CI: yanked dependencies are denied, unknown registries and unknown git sources are denied, wildcard versions are denied (path/workspace deps exempted), and a license allowlist excludes copyleft (GPL/AGPL/LGPL) licenses to keep the proprietary build shippable.
• RustSec advisories are tracked actively. Specific transitive dependencies are pinned to feature flags that avoid known-vulnerable code paths (for example, aws-config's default-https-client feature avoids the legacy connector-hyper-0-14-x stack that carries RUSTSEC-2026-0098/0099/0104; the prometheus crate is pinned to 0.14 to avoid the protobuf 2.x recursion issue RUSTSEC-2024-0437; the rustls-pemfile crate has been removed in favour of the rustls-pki-types pem module after RUSTSEC-2025-0134).

7.2 Security Testing

Proxara runs internal adversarial security reviews on a regular basis, covering the device proxy, the connector service, the classification API, the audit chain, and the MCP gateway. Independent third-party penetration testing is planned.

7.3 Responsible Disclosure

Security researchers may report vulnerabilities to security@proxara.ai. Proxara commits to acknowledging reports promptly and providing remediation timelines.

---

8. Incident Response

8.1 Incident Response Plan

Proxara maintains documented incident response procedures for security events affecting customer environments.

8.2 Breach Notification

• For most deployments, Proxara will notify affected customers within 72 hours of confirming a breach affecting their data.
• For healthcare deployments covered by the HIPAA BAA, notification follows the HIPAA Breach Notification Rule timeline (up to 60 days from discovery, per 45 CFR 164.410).
• Notification includes: nature of the breach, data affected, remediation steps, and recommended actions.
• See the Data Processing Addendum and HIPAA BAA for contractual commitments.

---

9. Compliance and Certifications

Every audit event is tagged at runtime with the specific control IDs it evidences. The bundled control library covers controls across ISO/IEC 27001:2022 (Annex A), GDPR, the EU AI Act (Regulation 2024/1689), NIST AI RMF 1.0, the HIPAA Security Rule, SEC Reg S-P, and further frameworks. The library is versioned: every audit event pins the exact library version that fired, so a retro-audit can reconstruct the rule set in effect at the time. Customer-supplied control overrides are additive only; baseline IDs cannot be removed or replaced.

Proxara's security program includes: internal adversarial security reviews; least-privilege IAM with SCP-enforced guardrails; IMDSv2 on all compute; private-subnet data stores; KMS-encrypted storage throughout; MFA-gated administrative access; and nightly automated audit-chain verification. Independent third-party penetration testing is planned.

---

10. Personnel Security

All Proxara personnel with access to customer environments are bound by confidentiality agreements.

---

11. Business Continuity

11.1 Customer Data Resilience

Proxara's deployment templates include:

• Multi-AZ database deployments (RDS) for high availability
• Automated database backups with configurable retention
• S3 cross-region replication available for audit archives

11.2 Disaster Recovery

Recovery Point Objective (RPO) and Recovery Time Objective (RTO) depend on customer deployment configuration. Proxara's deployment templates include multi-AZ databases and automated backups to support business continuity objectives.

If the classification API is unavailable, employee traffic passes through unredacted by default (fail-open) and the degradation is written to the record; the firm can set fail-closed instead, and traffic from automated agents is always held on failure. Employees are never blocked by a Proxara outage. Audit events are queued in an encrypted local queue and flushed when connectivity is restored.

---

12. Contact

For security inquiries, vulnerability reports, or to request detailed security documentation:

Security Team

Email: security@proxara.ai

For general privacy and data-subject inquiries:

Support

Email: support@proxara.ai

Proxara, Inc.

28 Geary St. Suite 650 PMB 5328

San Francisco, CA 94108