BLUEPRINT · SECURITY

Security

You are being asked to run our JavaScript on your production domain and, if you connect a source, to hand us a credential to your repository. This page says what we defend against, what we do not, and what we hold.

Last updated 2026-08-15.

What we do not claim

mAiSight holds no third-party security certification. We are not SOC 2 audited. We are not ISO 27001 certified. There is no penetration test report to send you. If a certification is a hard gate for your organization, we are not through it yet, and we would rather you learn that here than three calls in.

What we offer instead: the product is open source, so the claims below are checkable rather than asserted. The privacy properties in particular are held in place by tests in the public repository — if analytics ever began capturing personal data, the build would fail.

The reader path carries no personal data

For most customers this is the entire security review, because the widget never touches anything sensitive in the first place. It sets no cookies, writes no persistent identifier, and the analytics it emits never contain an IP address, a raw User-Agent string, or a Referer. Events are aggregated as they are written and the dashboard can only read aggregates. Details, including exactly what the script loads and sends, are on the privacy one-pager.

Threat model

The sharp edge is not the reader path — it is source-connected ingestion, where mAiSight stores a credential you issue (a GitHub App private key, a fine-grained PAT, an OAuth token, an object-store access key) so it can re-authenticate on every sync. Those are the threats we design against, in priority order.

1. Repository compromise. If our source files leak, the credential blobs in them stay unreadable. Secrets are never committed in cleartext and are never present in the source tree.
2. Host compromise. Read access to the encrypted store on the server yields ciphertext only. The decryption key is held separately from the encrypted material, is readable only by root, and is never part of any backup that leaves the host.
3. Process compromise. A worker running a sync holds decrypted credentials in memory for the duration of that run. Decryption is on demand and scoped to the sync. We accept this exposure and state it rather than hiding it — closing it requires hardware key isolation, which is on the Enterprise path and is not what we run today.
4. Log exfiltration. Every log line that could carry a credential goes through a redaction helper that substitutes a sentinel. Secret values do not reach logs.
5. Credential rotation on your side. When you rotate a credential, the resulting sync failure surfaces plainly in the source's status so you can replace the stored secret yourself, without opening a ticket with us.

Explicitly out of scope: side-channel attacks, kernel-level memory extraction, and any framework-specific compliance regime (FedRAMP, HIPAA, FIPS). None of those are claimed and none are engineered for.

How credentials are stored

• Encrypted at rest with sops and age. Both are widely-reviewed open-source tools rather than something we wrote.
• One encrypted file per credential. The database holds only an opaque reference to that file. There is no column anywhere that contains a secret.
• Encryption and decryption keys live outside the application's storage, on the host, reachable only by the service process.
• Rotated on a 90-day cadence, and immediately on suspicion of host compromise, on the departure of anyone with administrative access to the production host, or on a CVE in sops or age that affects the encryption guarantee. Rotation is zero-downtime; your syncs do not break while it happens.

Revocation and deletion

Deleting a connected source removes the source record and destroys its encrypted credential file in the same operation. Documents that depended on it are quarantined for 30 days before final unpublish, so an accidental disconnect is recoverable and an intentional one still terminates.

If our decryption key were ever lost, stored credentials would be unrecoverable and we would tell every affected customer to re-issue. Nothing else is lost in that scenario: glossary review state, published documents, and analytics are stored separately and are unaffected. We would rather have a loud, recoverable failure mode than a quiet escrow.

Where your data goes

Application data is hosted in the EU. Document text is sent to an extraction model — by default a hosted one, but you can point mAiSight at any OpenAI-compatible endpoint including a model you run yourself, in which case no third party ever receives your document text. The full list with regions is on the subprocessors page.

Reporting a vulnerability

Email codeblackwell@gmail.com with enough detail to reproduce. We will acknowledge within three business days. Please do not open a public issue for anything exploitable, and please do not test against another customer's documents — ask us and we will give you something to test against.