How CoApp Protects Customer Data

The threat model that shaped our architecture

CoApp sits inside browser-based clinical and business workflows. Content scripts read page DOM to surface alerts. The rule engine evaluates those values against configured thresholds. For a moment, however brief, CoApp touches data that describes real patients — diagnosis codes, optical measurements, insurance identifiers, transaction amounts. That creates a security obligation we take seriously.

Our threat model starts with a blunt question: what happens if our servers are compromised? For most SaaS products, the answer is bad — plaintext customer data is somewhere on disk or in a database, and an attacker with server access can reach it. We designed CoApp so that the answer to that question is: nothing useful. No plaintext customer data ever leaves the end user's browser or reaches our servers unencrypted. There is nothing to steal from a server breach because there is nothing readable on the server.

Browser-side key generation

Every CoApp installation generates an RSA-2048 key pair inside the browser at first launch, using the SubtleCrypto API built into every modern browser. The private key never leaves the browser — it is stored in chrome.storage.local and is never transmitted over the network. Only the public key is sent to our backend during device registration.

When CoApp captures a field value from a page — say, an out-of-range pupillary distance or a missing authorization code — that value is immediately encrypted client-side using AES-256-GCM before being transmitted anywhere. The AES key is itself encrypted with the browser's RSA public key and included alongside the ciphertext. The result is a payload that can only be decrypted by a system that has access to the corresponding RSA private key.

This architecture is not just a compliance checkbox. It is the security guarantee that makes it safe to run CoApp in clinical environments where HIPAA obligations apply and patient data sensitivity is high.

Processing inside AWS Nitro Enclaves

Some CoApp workflows require server-side computation — aggregating alert patterns across a location, running rule evaluations that require data from multiple sessions, generating reports. For these operations, we use AWS Nitro Enclaves.

A Nitro Enclave is a hardware-isolated compute environment that runs inside an EC2 instance but is cryptographically separated from the host. The enclave has no persistent storage, no external network access, and no way for the host OS — or anyone with access to the host — to inspect its memory. Code running inside a Nitro Enclave is verified against a known attestation document before it is allowed to receive decryption keys.

The decryption flow works as follows:

• An encrypted payload arrives at our backend — AES ciphertext plus the RSA-wrapped AES key
• The backend proxies the payload into the Nitro Enclave without touching the decryption keys
• The enclave requests the RSA private key from AWS KMS, presenting its attestation document to prove it is running verified code
• KMS validates the attestation and releases the private key only to the enclave
• The enclave decrypts the AES key, decrypts the payload, runs the computation, and returns only the result — never the plaintext source data

The RSA private key that KMS manages is distinct from the browser-side private key. It is a server-side key used for a different set of operations — specifically, decrypting values that have been explicitly authorized for server-side processing. The browser-side key remains in the browser and is never involved in server-side computation.

Attestation and the trust chain

The most important security property of Nitro Enclaves is attestation. Before KMS releases any key material to an enclave, it verifies a cryptographically signed document that describes exactly what code is running in the enclave — its hash, its signing certificate, and the software versions in the chain. If the code has been tampered with in any way, the attestation fails and KMS refuses the request.

This means our security does not rely on trusting our own servers or our own engineers not to do something wrong. It relies on AWS KMS, which has its own independent audit trail, and on the attestation chain, which is signed by AWS infrastructure. An attacker with full access to our EC2 instances cannot extract plaintext data because they cannot impersonate the enclave or forge its attestation document.

What we store, and what we don't

CoApp stores encrypted payloads, rule configurations, and alert metadata. We store enough to reconstruct alert history for a location — which workflow triggered an alert, what time it occurred, which rule matched. We do not store raw field values in plaintext. The underlying clinical or transaction data that CoApp reads from a page is encrypted before it ever reaches our servers and is only decrypted inside the enclave for the specific computation that requires it.

Rule configurations — thresholds, field patterns, action definitions — are stored in plaintext because they are customer-controlled parameters, not sensitive data. An operator who configures a rule that flags pupillary distances over 72mm is not exposing patient data by doing so; they are describing a check they want to run. That configuration is treated as business logic, not PHI.

Ongoing posture

Security architecture is not a one-time decision. CoApp's threat model, key rotation policies, and enclave code are reviewed on a regular cadence. We are working toward a SOC 2 Type II audit to give enterprise customers independent verification of our controls. In the meantime, we are happy to walk through our architecture in detail during any enterprise evaluation — reach out through the demo form and ask specifically about security.