> ## Documentation Index
> Fetch the complete documentation index at: https://docs.precipiq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Precipiq security architecture and data handling

> How Precipiq authenticates requests, protects your data in transit and at rest, and what you can independently verify about your records.

Precipiq is built around the principle that you should be able to verify what happened to your data without taking our word for it. Every decision record is hash-linked so tampering is detectable, forensic exports carry a cryptographic signature you can verify offline, and your API keys are stored only as hashes — we can't recover them if you lose them.

## Authentication

Precipiq uses API keys to authenticate all requests.

* Keys are 32-byte secrets prefixed with `pq_live_` for production or `pq_test_` for sandbox environments.
* Keys are stored by their SHA-256 hash only. The raw key is shown exactly once — at generation — and is never logged.
* WebSocket connections authenticate via an `api_key` query parameter. Browsers cannot set custom headers on the WebSocket handshake, so the query parameter is the required mechanism. Precipiq scrubs this parameter from access logs automatically so your key does not appear in log output.

Use `pq_test_` keys during development and integration testing. They are isolated from your production ledger and carry their own rate limits.

## Hash chain tamper detection

The ledger is append-only and hash-linked. Every decision record stores the SHA-256 of its predecessor in `prev_hash`, and its own `hash` is computed over a canonical JSON serialisation that includes `prev_hash`. Altering any single record corrupts the chain at every subsequent record — detectable in a single `verify_chain` sweep.

See [Hash Chain](/concepts/hash-chain) for a detailed explanation of how the chain is constructed and how to run verification yourself.

## Encryption

### In transit

All traffic between your application and the Precipiq API travels over TLS 1.2 or higher. The dashboard enforces HSTS with a two-year preload window, preventing protocol downgrade attacks.

### At rest

| What                         | How                                                                                                                                                                            |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Ledger data                  | AES-256 disk encryption at the storage layer.                                                                                                                                  |
| Forensic export signing keys | Per-org RSA-2048 private keys, encrypted at rest with a master secret held in a key management service. The private key never exists in plaintext outside the signing process. |

## Threat model

| Threat                                             | Mitigation                                                                                                         |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| API key leaked in client code                      | Sandbox keys (`pq_test_*`) for development; per-org rate limits; key rotation endpoint.                            |
| Replayed Stripe webhook                            | `stripe-signature` header verified; `external_id` idempotency prevents double-processing.                          |
| Mass reconnect from a shared IP                    | Per-IP WebSocket connection rate limit (30 per minute per IP).                                                     |
| Slow-consumer denial of service                    | Bounded per-connection queue; connections evicted on overflow.                                                     |
| Attacker with database write access alters history | Hash chain detects the alteration on the next `verify_chain` sweep.                                                |
| Forensic bundle altered after export               | RSA-2048 signature on `manifest.json`; recipient verifies with `openssl dgst -verify` without contacting Precipiq. |
| Cross-org data leakage                             | Every query is scoped to your organisation; strict data isolation is enforced at the database layer.               |

## Dependency hygiene

All Python and Node dependencies are version-pinned and audited for known vulnerabilities on every release. No runtime dependency on unmaintained packages.

## Compliance roadmap

<Info>
  These are planning targets, not commitments. Contact sales for the current status of any specific attestation.

  * **SOC 2 Type II** — planned; target window Q3 2026 subject to audit scheduling.
  * **ISO 27001** — being scoped for 2027.
  * **HIPAA BAA** — available on the Business plan and above. Contact sales for the signed BAA template.
</Info>

## Responsible disclosure

If you discover a security issue, email [security@precipiq.dev](mailto:security@precipiq.dev) with a proof of concept. We aim to acknowledge within two business days and will coordinate disclosure timing with you before any public write-up.

<Note>
  Precipiq does not run a public bug bounty program. Individual bounty arrangements are possible by prior agreement.
</Note>