Security at Cognisafe

Cognisafe operates as a logging and analysis layer, not a traffic proxy. In the default SDK integration, your LLM calls travel directly from your application to your LLM provider (OpenAI, Anthropic, etc.). Cognisafe never sits in that path.

After each LLM call completes, the SDK sends a copy of the request and response to the Cognisafe API asynchronously. This copy is stored, scored for safety threats, and surfaced in your dashboard. The critical property is: if the Cognisafe API is unreachable for any reason, your LLM calls continue unaffected.

Your app  ──────────────────────────────────►  LLM provider
              │                                      (OpenAI / Anthropic / etc.)
              │ async copy (non-blocking)
              ▼
         Cognisafe API  ──►  Safety scoring  ──►  Dashboard

Block mode (available on Team and Enterprise) places Cognisafe in the request path. See section 2 for the full trust model and architectural guarantees that apply when block mode is enabled.

These are meaningfully different trust contracts. Choose based on your risk tolerance.

Block mode architectural guarantees:

• Block or pass — never modify. The proxy can reject a request (returning an error to your application) or forward it verbatim to the LLM provider. It cannot alter the content of a request or response. This is enforced architecturally: the proxy hashes the request before forwarding and returns the hash to your SDK, which verifies it.
• Fail-open by default. If the Cognisafe proxy is unreachable, requests pass through directly to the LLM provider. Enterprise customers can configure fail-closed if their compliance posture requires it.
• mTLS between your infrastructure and our proxy. Both sides present certificates. A compromised or spoofed proxy cannot silently insert itself.
• Self-hosted proxy option (Enterprise). Run the proxy container on your own infrastructure. LLM traffic never leaves your network. See section 6.
• Proxy code is open source. The same transparency guarantee that applies to the SDK applies to the proxy binary.

In transit. All data between your application and the Cognisafe API is encrypted with TLS 1.3. mTLS is available for block mode and Enterprise customers.

At rest. Customer Data — including all stored LLM prompts, responses, and safety scores — is encrypted at rest using AES-256. Encryption keys are managed via Railway's secrets infrastructure and are rotated annually.

Database. PostgreSQL with column-level encryption forrequest_body andresponse_body fields, which hold the raw LLM content. These columns contain the most sensitive data and are encrypted independently of the row-level storage encryption.

Retention. Customer Data is retained for the duration of your subscription and deleted within 90 days of account termination. You can request earlier deletion at any time by contacting hello@cognisafe.uk.

Access controls. Production database access requires both VPN and hardware key authentication. No employee has standing access to production data — access is granted per-incident with full audit logging.

The following third-party services process Customer Data on our behalf. We maintain Data Processing Agreements with each. Enterprise customers can request a full DPA from us.

The Cognisafe SDK runs inside your production environment. We treat this as the highest- risk surface we operate and apply the following controls:

• Open source. The full SDK source code is published on GitHub. You can read every line before installing it, and verify that the PyPI release matches the published source via the build provenance attestation.
• Signed releases. Every PyPI release is signed using PyPI Trusted Publisher attestations (Sigstore). You can verify the signature independently before deployment.
• SHA-256 checksums. Published alongside every release. Pin to a specific version and hash in production: cognisafe==x.y.z --hash=sha256:...
• Pinned dependencies. The SDK has no unpinned transitive dependencies. Dependency confusion and typosquatting attacks are mitigated by explicit version locking in the published package.
• Minimal network footprint. The SDK makes outbound connections to exactly one endpoint: api.cognisafe.uk. It makes no other network calls. You can verify this by reading the source or by running the SDK under a network firewall allowing only that domain.
• No code execution. The SDK does not execute any code it receives from our API. It sends data outbound and receives acknowledgement responses only.

Enterprise customers who cannot route data through Cognisafe infrastructure — due to regulatory requirements, data residency constraints, or security policy — can run the entire Cognisafe stack on their own infrastructure.

The self-hosted option includes:

• The Cognisafe proxy as a Docker container image (signed, published to our registry)
• The scoring worker, which you configure to use your own OpenAI key or a local model
• The dashboard, deployable to your own domain
• Your own PostgreSQL and Redis — no data leaves your network

In self-hosted mode, Cognisafe has zero access to your LLM traffic or Customer Data. We provide software and updates; you own the infrastructure and the data.

Contact hello@cognisafe.uk for Enterprise pricing and a self-hosted deployment guide.

We welcome vulnerability reports from security researchers. Our policy:

• Report by email to security@cognisafe.uk. You can use our PGP key (linked below) to encrypt the report.
• We will acknowledge receipt within 48 hours and provide an initial assessment within 5 business days.
• We ask for 90 days before public disclosure to allow remediation. We will work with you on the timeline if a fix requires more time.
• We do not pursue legal action against researchers acting in good faith under this policy.
• We will credit researchers in our acknowledgments section (below) unless you prefer to remain anonymous.

In scope: cognisafe.uk, the Cognisafe API, the Python SDK, the proxy, and any subdomain.

Out of scope: Denial of service attacks, social engineering of staff, physical security, and automated scanning that generates excessive load.

No vulnerabilities have been reported to date. Researchers who responsibly disclose valid issues will be credited here.

Our machine-readable security policy is available at /.well-known/security.txt per RFC 9116.