Proxaradocs
Trust Center/Security review

The device security review

The review path before an Endpoint Protection device pilot: the documents in order, the question each one answers, the stated limits of the system, and direct answers to the questions reviewers ask.

Updated July 2026

Before a firm approves a device pilot, someone has to be able to veto it. This page is the review path for that person: the documents in order, the question each one answers, the limits of the system stated plainly, and direct answers to the questions reviewers ask most. It covers the Endpoint Protection device agent; the hosted connector has its own path at the Connect security review. Proxara sends this same path as the security review package on the day of the review meeting of the Endpoint pilot.

The review path

Read in order. Each step names the question it answers, the document that answers it, and what the document contains.

  1. How does it work on the device? How Proxara works, then The device proxy. The path a prompt takes end to end, how the interception decision is made, and the never-block gates.
  2. What is the security architecture? Security Overview. The reference document for security teams: components, encryption, access controls, audit logging, and compliance status.
  3. What is decrypted, and what never is? Redaction and tokenization, plus Stated plainly on this page. Decryption requires positive evidence that a destination is an AI service; the exclusions and the failure paths are below.
  4. How are certificates and keys handled? Certificates and keys on this page. Where the private key lives, how leaf certificates are minted, and which scoping is cryptographic versus enforced in software.
  5. What data leaves the device, and where does it go? Product Privacy Policy, Data Processing Addendum, and the Sub-processor List. What is processed, under what terms, and which providers are involved.
  6. What environment does the firm run in? The private environment. The dedicated, single-tenant AWS environment Proxara provisions per firm for pilots and paid deployments.
  7. How does it deploy, and how does it come off? MDM rollout, Network endpoints, and Rollback and uninstall. The push, the allowlist, and the exact restore.
  8. Does it hold up on this firm's stack? Single-device validation. The hands-on checklist the pilot's one-laptop step runs on one IT-controlled Windows machine before any employee device is touched.
  9. What are the terms? Endpoint Protection Pilot Terms, Master Subscription Agreement, and Service Level Agreement. The pilot contract, the subscription contract behind it, and the availability commitments.

Certificates and keys

The facts a reviewer needs, as implemented.

  • One certificate authority per firm. The interception CA is per tenant, shared by the firm's devices. It is not per device. For pilots and customers it is minted server side during enrollment, and the certificate and its private key are delivered to each device over the authenticated enrollment channel.
  • Where the private key lives. On each device, in the agent's data directory. On macOS the key file is created with owner-only permissions (mode 0600), readable by the root daemon alone, and the permission is re-asserted on every load. The key is a file protected by operating system permissions; it is not hardware-bound.
  • Leaf certificates. Minted in memory, per destination host, on demand, with a one-year validity, and cached in memory. They are never written to disk.
  • What the CA is scoped to. The CA certificate carries X.509 name constraints that exclude banking, healthcare, government, sign-in and identity, and operating-system and security-tooling domains. The exclusion is written into the certificate itself, where an auditor can read it.
  • Which scoping is cryptographic, and which is software. Firefox enforces name constraints cryptographically. macOS does not reliably enforce them on user-added roots. The operating control on every platform is therefore the agent's runtime interception gate, which refuses the excluded categories before any AI check; the certificate constraints are defence in depth.

Stated plainly

The limits of the system, stated as exactly as the code supports.

  • Certificate-pinned applications are not intercepted. Known pinned and sensitive surfaces sit on a curated denylist and pass through untouched, and a process-level bypass passes through desktop applications known to pin, such as the ChatGPT desktop app. If a host the agent does intercept fails at the origin, the agent drops that host to a direct tunnel for five minutes and records a content-free compliance event. Bypasses and degraded coverage are reported, never hidden.
  • Hard exclusions run before any AI check. Banking, healthcare, government, sign-in and identity, operating-system update, and security-tooling hosts are never decrypted. Authentication and credential exchanges are never analyzed or modified.
  • Microsoft. Microsoft sign-in and identity traffic is never touched. Coverage of Microsoft AI surfaces follows the AI-host registry; there is no blanket exclusion and no blanket coverage claim for Microsoft 365 or Copilot.
  • When classification fails, the default is fail open. If classification fails or times out, employee traffic passes through unredacted by default. A firm can set fail closed instead, which blocks the request until classification succeeds. Automated agent traffic is always held on failure rather than sent raw. The agent logs the failure, and when an intercepted destination is bypassed after an origin failure, a content-free compliance event goes on the record.
  • Capture on Windows is a Microsoft-signed driver; trials and macOS ride the system proxy. On Windows production installs, capture uses a network driver signed by Microsoft through its hardware certification program. It carries web connections through the agent's local checkpoint, where only destinations with positive AI evidence are opened and everything else passes through unread, and its authorization lapses within seconds if the agent stops being healthy. Trial and sandbox installs, and macOS today, capture through the operating-system proxy configuration scoped to registry AI hosts; on those installs, applications that ignore the OS proxy are not silently covered. Every device reports which capture mode it is running.
  • The QUIC lane follows the capture mode. On Windows production installs, the driver declines UDP on port 443 only while the complete capture path is live, so browsers retry over connections the checkpoint reads; when the path is not live, nothing is declined and traffic flows natively. No durable firewall rule and no browser policy is left behind. On macOS the managed profile disables QUIC, encrypted client hello, and DNS over HTTPS for Chrome, Edge, and Firefox.
  • Platform notes. On Macs enrolled in MDM, certificate trust arrives through the trust profile without user interaction on supervised or user-approved devices; on unmanaged trial Macs it is a one-click prompt into the user's login keychain. On Windows the service installs the certificate into the machine root store, and managed fleets deliver the same certificate through the MDM trusted-certificate profile.

Questions reviewers ask

What happens if the agent is removed or stops?

Traffic flows natively. Interception exists only while the agent is running with a trusted certificate. On Windows production installs, the driver's authorization is a short lease renewed by the healthy agent; when the agent stops, the lease lapses within seconds and connections proceed natively. On proxy-mode installs, the proxy configuration the agent writes routes only registry AI hosts to the local proxy and names a direct fallback for them; every other destination is already direct. If the certificate is not trusted, the agent disables interception, removes the system proxy configuration, and alerts the operator. Uninstall restores the recorded prior state; the exact sequence is in Rollback and uninstall.

Can a local administrator extract keys, and what is the blast radius?

The CA private key is a file on the device, and an administrator with root or system access can read what the operating system grants that access. The CA is per tenant, so extraction on one device is extraction of the firm's CA. Two bounds apply, stated exactly: the certificate's name constraints exclude banking, healthcare, government, sign-in, and security tooling from what any certificate minted under it is valid for, and verifiers that enforce constraints reject violations cryptographically. Firefox enforces them; macOS on user-added roots does not reliably. The evidence supports exactly this much. Firms with stricter key-custody requirements can raise them at the review meeting.

Does it interfere with EDR or the VPN?

Coexistence covers this in full. In short: the agent changes proxy configuration, certificate trust, and AI-client configuration, and on Windows production installs it adds one Microsoft-signed capture driver whose authorization lapses within seconds if the agent is unhealthy. It changes no routes or DNS settings and adds no firewall rules on any install. Security-tooling hosts are excluded from interception both at runtime and in the certificate's name constraints, and when any origin connection fails, the agent steps aside so the firm's own controls decide.

Who can read decrypted content?

For traffic with positive AI evidence, the agent sends the prompt text and file content to the analysis service in the environment the firm is enrolled in, where AWS Bedrock classifies it. The AI provider receives the redacted version. When sensitive values are found, the original text is kept in that environment as signed compliance evidence alongside the redacted version; clean exchanges are stored content-free, and raw file bytes are never persisted. The record is read from the firm's console. For pilots and paid deployments, Proxara provisions a dedicated, single-tenant AWS environment per firm; the trial sandbox and demo run on Proxara-operated infrastructure with per-tenant isolation and deletion at the end.

How does an examiner or auditor verify the record?

Events are signed on the device with a per-device key and hash-chained; the server verifies the signature and the chain continuity before accepting an event. Batches are anchored by Merkle root to a public transparency log (Sigstore Rekor) by default; the log receives a hash and a public key, never content. Exports are self-contained verification packs: the signed bytes, the device public keys, the inclusion proofs, the anchors, and a bundled verifier, so the record verifies offline.

What does Proxara itself receive?

Device heartbeats and signed events go to the firm's environment, not to Proxara. Operational telemetry that crosses to Proxara is person-free: counts, versions, and percentiles, with no names, no hostnames, and no content. Every frame that crosses is mirrored to a ledger the firm can read in its own console before it is sent.

How do updates arrive, and are they verified?

Signed, hash-verified silent updates are live for production agents pinned to a release: the agent checks its tenant's API, downloads from the pinned release host, verifies the SHA-256 the server declared before the file is written to disk, verifies the platform code signature, and installs silently. Trial installs do not auto-update; they update by reinstall.