Multi-tenant. Licence-gated. Fail-closed.

Tenant isolation

• Per-tenant API keys with constant-time comparison — no shared credentials.
• TenantEnforcementMiddleware validates tenant identity on every request; cross-tenant access is architecturally impossible.
• Tenant kill-switch: any tenant can be suspended immediately via a signed operator action.
• All data is tagged with a verified tenant identifier before storage; mixed writes are rejected at the service layer.

Licence & capability gating

• Every platform capability is activated by an EV code-signed manifest — no capability can load without a valid signature.
• Three-gate module loading: manifest presence + tier authorisation + integrity hash. All three must pass.
• Verification failure drops the platform to MRI-only read mode. No silent fallback to a higher tier.
• The EV private key never enters the repository or CI/CD environment.

Human-in-the-loop controls

• Every automated remediation action requires explicit human operator approval (Core+ tiers).
• Agent-generated decisions are logged with evidence references before any action is taken.
• Operators must authenticate via JWT Bearer; unauthenticated approval requests are rejected.
• Approval decisions are immutably recorded with operator identity and timestamp.

Identity & authentication

• JWT Bearer authentication for operator and API access.
• Per-tenant API key authentication with the canonical X-API-Key header; keys are stored hashed and legacy aliases are transitional only.
• TOTP multi-factor authentication available for all user accounts.
• Account lockout enforced after repeated failed authentication attempts.

Authorisation

• Role-based access policies: MRI tier is read-only; write capabilities are gated to Core+ tiers with a signed licence.
• Admin endpoints require verified operator identity; unauthenticated access returns 401.
• Privileged operations require an additional authorisation check against a Human Operator policy.
• Write permission is evaluated per-tier and per-capability at the request layer.

Rate limiting

• Redis-backed atomic rate limiting using Lua INCR+EXPIRE scripts — no race conditions.
• Rate limit state is partitioned per API key, preventing cross-tenant interference.
• Requests exceeding limits return HTTP 429 with a Retry-After header.
• In production, Redis unavailability returns 429 (fail-closed). In development, fail-open for local iteration.

In transit

• TLS 1.2+ enforced on all platform endpoints. TLS 1.0 and 1.1 are disabled.
• HTTP Strict Transport Security (HSTS) with max-age=31536000 enforced in production.
• Webhook payloads are signed with HMAC-SHA256 so receivers can verify authenticity.
• All outbound connector requests use TLS certificate validation; insecure connections are rejected.

At rest

• PostgreSQL, Redis and blob storage encrypted at rest with AES-256.
• Encryption is managed at the deployment and application layers using the contracted infrastructure key management path for that environment.
• API keys are stored as hashed values; plaintext keys are never persisted.
• Sensitive configuration values are loaded from HashiCorp Vault at runtime; never stored in code or environment files.

Signing & key management

The EV signing private key is held in a DigiCert HSM and never appears in source control, CI/CD pipelines, or deployed artefacts. Per-startup ephemeral keys are used in development; production keys must be provisioned via Vault.

Evidence integrity

Null or blank actor fields cause the audit write to be rejected at the service layer — no anonymous actions.

Retention & export

• Minimum 7-year audit log retention (legal obligation; configurable upward per contract).
• Audit logs are exportable on demand for regulatory proceedings, investigations, and formal evidentiary review.
• Structured JSON export available via the DSAR API endpoint.
• Tribunal-grade verification depends on the export and verification path used; append-only storage alone is not the same as standalone non-repudiation.

What is logged

• Operator identity (authenticated subject from JWT claim).
• Timestamp and correlation ID for every event.
• Capability ID, tier, signature verification result and module hash on every activation.
• Human approval decision, evidence reference and policy outcome for every privileged action.

Cyber Essentials

• Certified. Current certificate details are available through procurement review on request. Contact security@identityfirst.net.
• Covers: boundary firewalls, secure configuration, access control, malware protection, patch management.

SOC 2 Type II

• Audit in progress. Third-party auditor engaged.
• Controls mapped to Trust Services Criteria: Security, Availability, Confidentiality.
• No SOC 2 Type II report is claimed as issued on this page. Interim security materials may be shared under NDA where appropriate.

ISO 27001

• ISMS established. Gap assessment complete.
• External certification audit scheduled for 2026.
• No ISO 27001 certification is claimed as issued on this page. Additional documentation is shared only where actually available and appropriate to the diligence process.

How to report

• Email security@identityfirst.net with a clear description of the vulnerability.
• Include steps to reproduce, affected component and potential impact assessment.
• PGP encryption available on request for sensitive reports.
• We request a 90-day coordinated disclosure window before public disclosure.

Response SLAs

• We do not take legal action against researchers acting in good faith.