Security Overview
Architecture for both products, including the Proxara Connect hosted connector, encryption, network isolation, access controls, audit logging, vulnerability management, the cryptographic audit chain, and compliance status.
Updated July 2026
Security Overview
Last updated: July 2026
This document describes the security architecture, controls, and practices behind 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. It is written for customer security teams, compliance officers, and third-party assessors conducting vendor due diligence. Section 12 covers the archived device agent, retained for firms already running it.
The reviewer-ordered walk-through, with the limits of the system stated plainly, is The Connect security review. The regulatory analysis is IRC § 7216 and the disclosure boundary.
1. Architecture
1.1 Isolation, and control
Every stage of one authorized piece of work runs inside a single-tenant environment provisioned for one firm: retrieval, document parsing, classification, local reasoning, the release compiler, the stand-in vault, the private workspace, execution, and the record. There is no shared multi-tenant plane holding customer data, and nothing installs on any device.
That is isolation. Control is a separate set of facts, and every deployment records which of two modes is active: a firm-owned account or subscription with a revocable Proxara deployment role, or an explicitly contracted isolated managed account. Either mode records the same facts in writing.
| Control fact | Recorded for every deployment |
|---|---|
| Account | Which account or subscription, which region, whose name |
| Root and tenant administration | Who holds it |
| Encryption keys | Who owns them; who holds use rights only |
| The Proxara deployment role | Its exact permissions, and how the firm revokes it |
| Support access | What exists, who authorizes a session, when it expires |
| Network paths | Every route in and out, including the ones that do not exist |
| Model and container origin | Where local model weights and serving images come from, and their digests |
| Exit | How the firm suspends, exports, or removes the system |
A dedicated account inside a provider's organization never stands in for a row above. The hosted demonstration is separate from all of this: it runs on Proxara-operated infrastructure with a synthetic practice tenant and per-tenant logical isolation, and everything it stores is deleted at the end.
1.2 Trust zones
| Zone | Holds or does | Egress |
|---|---|---|
| Control plane | Customer identity, approved work definitions, processor and destination profiles, connector registration, employee authority, content-free operational state | Content-free lifecycle only |
| Source and retrieval | Provider configuration, encrypted credentials, source-scoped employee grants, capability snapshots | Only the exact provider endpoints each connection requires |
| Local context and privacy | Raw source payloads, client and tax documents, clear identities, extraction state, classifications, exact calculation, cumulative disclosure state, stand-in mappings, release compilation | None |
| Customer-contained inference | Models approved to receive raw or sensitive customer context | None |
| External model gateway | Validated release packages, destination mapping, response schema validation | Approved model endpoints only |
| Private workspace | Clear rendering to one authorized employee under the firm's own sign-on | Customer API only |
| Execution | Durable bound intent, one-use target capabilities, provider action credentials, read-back and reconciliation | Only the exact provider action endpoints |
| Evidence and operations | Content-minimized projections, retention, support-access records | Content-free |
The external model gateway holds no source credential, no raw datastore permission, no clear identity, no stand-in mapping, no private-artifact key, and no execution capability. Proxara HQ has no routine access to client content, model prompts, clear artifacts, provider credentials, or customer encryption keys.
1.3 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.
| Lane | What it does | What it may receive |
|---|---|---|
| Deterministic local | Extraction, validation, exact calculation, target binding, read-back | Raw firm data |
| Customer-contained model | Document and tax-data classification, OCR correction, sensitive cross-source reasoning, candidate claims | Raw firm data |
| Approved external model | Drafting, organizing, sequencing, planning | Only the constructed release package |
| Explicitly authorized raw external | Only a purpose, processor, data class, and destination the firm separately authorized | As configured; never a fallback |
The customer-contained plane has no external route, no provider credentials, and no independent access to a source system. Its model artifact, tokenizer, serving image, and prompt templates are pinned by digest and attestable, and models do not self-update.
A managed model endpoint reached over a private network link remains a managed external processor. Network privacy and processing containment are different properties, and this document does not present one as the other. There is no silent fallback between lanes: if the local plane is unavailable, the work waits, returns a local-only result, or stops.
1.4 The release boundary
The compiler starts with no output and emits only typed claims the firm's policy admitted for that work, purpose, destination, and recipient. It does not start with a document and remove what a detector recognized.
The model does not receive the firm's documents with the sensitive parts removed. It receives a payload assembled only from claims the firm's policy authorized, and anything the system cannot account for never leaves.
Before release the 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, that stand-ins belong to the current namespace, and that the cumulative state for that destination is current. A residual scan of the finished envelope is one of those checks, not the mechanism. 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. 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.
1.5 Private rendering
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 possession of a URL is not authorization.
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 reason the workspace is first party rather than embedded is that 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.
1.6 Access model
One tenant-wide administrator consent grants delegated, read-only Microsoft permissions, so the connector can only ever reach what each signed-in employee can already reach. 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. Retrieving and acting are separate consents, and two independent checks fail the environment if the granted set is anything other than the reviewed one.
The application appears in the firm's own Entra admin center under Enterprise applications, where the firm can inspect, restrict, or revoke it unilaterally. A consent alone activates nothing: activation completes only when a real employee signs in and one live read proves the exact tenant, directory object, application, and token.
1.7 Truthful completion
A provider's success response is not evidence that an effect happened. Durable intent is recorded before any mutation, 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.
2. Data Protection
2.1 Encryption in transit
| Path | Encryption |
|---|---|
| Private workspace to customer API | TLS 1.2+, first-party origin, authenticated recipient-bound session |
| Domain cell to provider endpoints | TLS 1.2+ over the exact allowlisted endpoints for that connection |
| Privacy plane to customer-contained inference | TLS 1.2+ on a private authenticated API with no internet route |
| External gateway to approved model endpoint | TLS 1.2+, release package only, customer-approved retention and transport settings |
| Console to API | TLS 1.2+ |
2.2 Encryption at rest
All storage inside the firm's environment is encrypted with dedicated AWS KMS keys. Who administers them is a per-deployment control fact recorded per mode: in the customer-owned mode the firm administers them and revokes Proxara's use at any time.
| Storage | Encryption |
|---|---|
| PostgreSQL (RDS) | AES-256 via KMS; Multi-AZ in production; private subnets; not publicly accessible |
| Object storage for source objects, documents, and audit archives | AES-256 via KMS; Object Lock in COMPLIANCE mode for the record; versioned; insecure transport denied |
| Redis | Encryption at rest and in transit; AUTH token required |
| Secrets Manager and log groups | KMS-encrypted with the firm's own key |
2.3 Key management
Dedicated KMS keys are provisioned for database encryption, record encryption and signing, and general-purpose encryption of secrets and supporting storage. Proxara holds use rights only and cannot delete, disable, or modify key policies; the deployment record names who administers them. Purpose-specific data keys and envelope encryption separate raw, mapping, artifact, execution, and evidence access, and expiring stand-in continuity is removed by destroying its derived key.
2.4 The stand-in 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. Restoration of an original value happens in one place only: the private workspace, after live employee, work, purpose, and policy authority is re-checked.
A client keeps one stand-in for as long as the authorized work and its destination require, and it rotates when the work, purpose, or destination changes, so nothing can be assembled across tasks or days.
2.5 Retention
Retention is a class, not one number. Each class carries a purpose, an expiry, and an erasure method.
| Class | Expiry and erasure |
|---|---|
| Retrieved source objects and parsed document units | The class the approved work declares; deleted with their keys |
| Stand-in mappings | Explicit expiry, durable while an effect can still be verified or repaired, then cryptographically erased |
| Clear artifacts and private projections | The artifact's class; deleted with its key |
| Release attestations and the work record | The firm's evidence term; write-once until it expires |
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. Volatile caches are optional; they are never the authority. Offboarding or termination deletes retrieved content, working state, the vault, and grant tokens, and the deletion is certified in writing.
There is no mailbox or drive copy: content is fetched when asked, and every piece of work re-reads from the source system at that moment.
2.6 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 firm's environment holds only its own grant tokens, encrypted at rest and bound so a sealed token is unreadable in any other environment or row. No central Proxara service holds customer provider tokens.
3. Network Isolation
- Private subnets for compute and data stores; public subnets only for the load balancer and NAT.
- The raw-processing, privacy, and customer-contained inference planes have no default internet egress.
- Each domain cell may reach only the exact provider endpoints its connection requires. There is no arbitrary URL fetch and no open provider proxy.
- The external model gateway may reach only approved model endpoints and holds no permission on raw stores, mapping vaults, private artifacts, provider credentials, or execution.
- Execution workers may reach only the exact provider action endpoints for a bound effect.
- Workspace ingress is authenticated at a first-party origin under the firm's own sign-on.
- The HQ lifecycle path is separate and content-free.
Data residency. Processing and storage stay within the firm's environment in the region the firm selected. What leaves goes to parties the firm chose: the constructed release package to the firm's own approved model endpoint, and bound effects to the firm's own systems of record. None of the firm's content goes to Proxara.
Operational telemetry. Proxara receives only schema-bound, content-free counters from the environment: service status, coverage counts, error-template counts, and resource utilization. Every payload is validated at egress against a fixed schema and a deny-pattern filter, carries no free text, and identifies the environment rather than any individual. Every frame is mirrored to a ledger the firm can read in its console.
4. Access Controls
4.1 Authentication and authorization
| Interface | Method |
|---|---|
| Private workspace | Customer single sign-on, recipient-bound session, authority recompiled on every read and mutation |
| Console | Firm-managed sign-in; role-based access; every action logged with actor and timestamp |
| Registered applications and firm-built agents | Application principal, signed and replay-fenced commands, task-scoped definition discovery, no standing provider credentials |
| Cloud infrastructure | IAM roles and policies; IMDSv2 enforced; least privilege by workload role |
Roles are separated by workload rather than shared: raw source and document read, local inference invocation, release signing and verification, external dispatch only, private artifact access, provider credential retrieval and effect dispatch, evidence projection, lifecycle and migration, and content-free health. Negative permissions are part of acceptance: the external gateway cannot read raw, document, mapping, or private stores; local inference cannot call an external model, a provider, or HQ; the workspace cannot obtain provider credentials; and an execution worker cannot browse arbitrary source context.
4.2 Operational access
Where a firm asks Proxara to operate its environment, that access uses least-privilege IAM roles, is gated by two-factor sign-in and a per-firm external identifier, is logged in CloudTrail, and is customer-visible. A firm that wants none of it runs the same stack with the deployment role left unset. Which mode is active is recorded per Section 1.1.
4.3 Untrusted content
Retrieved documents, messages, and provider fields are data, never instruction authority. Source text is marked by origin and provenance, firm policy is never assembled from document text, model inputs and outputs use closed schemas, available actions are compiled independently of model text, and real identifiers and credentials stay local. Every provider operation is revalidated at execution and read back afterwards. Every new tool result re-enters the release compiler before another model step.
The design does not depend on recognizing every malicious sentence, and detection adds defense rather than carrying the claim. What bounds the risk is structural: retrieved content is data and never instruction authority, a proposal is typed against a closed vocabulary, and every target and citation in it must resolve to a stand-in and a source item from that same piece of work.
4.4 Rate limiting
Hot-path endpoints enforce per-client rate limiting with a burst window, and clients exceeding the limit receive HTTP 429 with Retry-After.
5. The Record
5.1 What is recorded
Each piece of work records the requesting principal, the approved work definition and purpose, the authority revision, which source capabilities were consulted, what was correlated or deliberately kept separate, which claims were released to which destination and processor, what stayed private or was omitted, what the planner proposed, which target was bound locally, what intervention occurred and why, what was attempted, what authoritative state was observed, what was repaired, and the final outcome.
Rows hold counts, categories, timestamps, and reference codes. No field exists for the request text, the material read, a client name, or a stand-in.
5.2 Integrity
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 for one request carries the verbatim signed bytes, the signatures, and the public keys, so a reviewer can verify it with their own tools. Proxara re-verifies an export before releasing it and refuses to serve one that does not verify.
Proxara ships no verifier program for the Connect record, and that record carries no transparency-log anchor and no inclusion proofs. The device agent's own chain, described in Section 12, is anchored differently.
5.3 Console actions
Console actions are recorded in an append-only log holding the event identifier, the action taken, the actor, a UTC timestamp, and action-specific detail. Entries are never updated or deleted, and the log carries metadata only.
5.4 Compliance archive
Proxara is a processing and execution boundary, not the firm's system of record. Where the firm forwards records to its own archive, that provider's agreement and retention policy govern them.
6. Data Minimization
| Principle | Implementation |
|---|---|
| Constructed release | The external payload is assembled from admitted typed claims, never carved out of a raw document |
| Local exact work | Correctness-sensitive calculation and comparison stay local; random perturbation is not used where it could alter tax logic, reconciliation, filing, or an employee's understanding |
| Indirect identification | Combinations are evaluated, not only spans: rare industry and location, entity form, exact date and amount, address fragments, document combinations, and persistent aliases |
| Content-free records | Supervision is evidenced through decisions, counts, and outcomes rather than retained content |
| No standing copy | Source systems stay authoritative; Proxara persists only what the work and recovery contracts require |
| Cross-client isolation | Documents, caches, embeddings, model context, and agent memory are bound to one firm and one piece of work |
7. Vulnerability Management
- Application dependencies are managed per language toolchain, reviewed, and updated on a regular basis.
- Container images, model artifacts, parsers, and infrastructure plans are pinned by digest and carry provenance.
- Internal adversarial security reviews cover the retrieval path, the release compiler, the customer-contained inference plane, the external gateway, the private workspace, and the execution kernel.
- Independent penetration testing and architecture review are release gates, not optional extras.
- Security researchers may report vulnerabilities to security@proxara.ai. Proxara acknowledges reports promptly and provides remediation timelines.
8. Incident Response
Proxara maintains documented incident response procedures for security events affecting customer environments. Affected customers are notified within 72 hours of a confirmed breach affecting their data. For healthcare deployments covered by the HIPAA BAA, notification follows the HIPAA Breach Notification Rule (up to 60 days from discovery, per 45 CFR 164.410). Notification includes the nature of the breach, the data affected, remediation steps, and recommended actions. Contractual commitments are in the Data Processing Addendum and the HIPAA BAA.
9. Compliance and Frameworks
Proxara does not certify a firm as compliant and does not enforce a statute. It makes the firm's own decisions enforceable in the path where AI retrieves data and completes work, and produces the record.
| Framework | Status |
|---|---|
| GDPR / UK GDPR | DPA with Standard Contractual Clauses (Module Two) and UK IDTA available; processing within the firm's selected region |
| CCPA/CPRA | Service Provider obligations documented in the DPA |
| HIPAA | BAA available for healthcare deployments |
| IRC § 7216 | Analyzed in IRC § 7216 and the disclosure boundary; Proxara enforces the firm's counsel-approved policy and never states a legal conclusion on the firm's behalf |
| AWS | AWS maintains ISO 27001, SOC 1/2/3, PCI DSS, and FedRAMP certifications |
Every record entry is tagged at runtime with the control identifiers it evidences, from a versioned control library, so a retrospective review can reconstruct the rule set in effect at the time. Customer-supplied control overrides are additive only.
10. Personnel Security
All Proxara personnel with access to customer environments are bound by confidentiality agreements, and their access follows Section 4.2.
11. Business Continuity
Deployment templates include Multi-AZ databases, automated backups with configurable retention, and optional cross-region replication for the record archive. Recovery objectives depend on the firm's deployment configuration.
Restore re-establishes schema authority, key access, transaction monotonicity, credential revocation posture, lease fencing, stand-in expiry, release predecessor chains, and execution truth. Restored credentials and pending effects do not become live until customer authority is reaffirmed where required. A Proxara outage never resolves itself by sending unprotected data: work waits, returns a local-only or partial result, or stops.
12. The Device Agent (Archived)
This chapter is retained for firms already running the Proxara device agent. It is outside Proxara Connect, and it is not part of the Connect architecture described above.
The agent is a signed background service on managed macOS and Windows devices, deployed through the firm's MDM. It decrypts a connection only on positive evidence that the destination is an AI service, matched against a registry of AI sites and applications served from the control plane; everything else is tunnelled through without decryption. Sign-in and identity, banking and payments, healthcare, government, OS-update, and security-tooling destinations sit on a never-inspect list that runs before any AI check, and are also excluded in the per-tenant CA's X.509 Name Constraints (RFC 5280), which a security team can parse straight out of the certificate.
Firefox and other NSS-based software enforce those constraints cryptographically. macOS does not reliably enforce name constraints on user-added roots, so the operating control there is the agent's own runtime gate; the certificate constraints are defence in depth on top of it.
The agent never blocks. If the CA is not trusted, interception disables entirely, traffic flows natively, no certificate is presented, 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.
The CA private key is stored in a system-protected directory at file mode 0600, owned by the system account, and re-asserted on every load; per-host leaf certificates are minted in memory and never written to disk. One uninstall removes the CA from every OS trust store it was placed in, restores the system proxy to its exact prior state from a snapshot, restores client configurations from backups, and removes the service registration and the entire data directory including key material.
Device-side records are signed per device and hash-chained per firm, batched into an RFC 6962 Merkle tree on a five-minute cadence, and anchored by default to the Sigstore Rekor public transparency log; the anchor carries the root hash and the anchor public key, never content. A bundled offline verifier confirms signatures, chain continuity, inclusion proofs, and the anchor without contacting Proxara. Device interaction records purge on a rolling window, seven days by default and configurable; signed proofs archive under COMPLIANCE-mode Object Lock with a seven-year default; aggregate metrics are retained for ninety days by default. The on-device vault seals each original value under its own AES-256-GCM key, and retiring a token destroys that key.
13. Contact
Security inquiries and vulnerability reports: security@proxara.ai
Privacy and data-subject inquiries: support@proxara.ai
Proxara, Inc.
28 Geary St. Suite 650 PMB 5328
San Francisco, CA 94108