Skip to main content

Trust Center

Security and operational posture

Tricognita is a multi-tenant security platform. This page summarizes what we do, what we don't yet do, and how you can verify both.

At a glance

Hosting
Vercel (BFF) + Fly.io (Go API)
Database
Neon Postgres
Cache / queue
Upstash Redis
Data region
Configurable per deployment (Asia-Pacific default)
Encryption at rest
AES-256 across Postgres, Redis, S3
Encryption in transit
TLS 1.2+, HSTS preload-eligible

Authentication and authorization

Tricognita uses HMAC-SHA256 signed session cookies with a 15-minute lifetime and a 7-day refresh token scoped to the refresh endpoint. Tokens are bound to the user agent at issuance time and include a per-issuance unique identifier that participates in server-side revocation.

Authorization runs through three independent layers — edge middleware on path prefixes, per-handler role checks in every BFF route, and page-level capability guards. A privilege-escalation bug would require simultaneous failures in all three.

Tenant isolation

Every customer-data row carries a tenant id. The tenant id is part of the signed session, part of the JIT token minted for upstream calls, and part of every database query. The browser-side cache is flushed on tenant transitions.

Cross-tenant access for support purposes goes through a documented admin flow that is audit-logged. We do not allow silent impersonation.

Audit logs

Every state-changing action — login, scan, remediation approval, credential change, policy edit, incident transition, export — is recorded in an append-only audit log with hash-linked tamper evidence. Audit logs are never deleted, and customers can export their full audit trail at any time.

Webhook security

Outbound webhooks are signed with HMAC-SHA256 using a per-subscription secret. Signature header follows the Stripe convention (t=…,v1=…) and customers should verify with a constant-time comparison and reject signatures older than 5 minutes.

We send webhooks; we do not receive them. There is no inbound webhook endpoint to attack.

Telemetry posture

We collect product usage signals (which pages are visited, which workflows complete) for internal product decisions. We do not load any third-party analytics SDK. Telemetry events carry a one-way truncated SHA-256 of the user's email — never the email itself. We do not capture IPs, cookies, form contents, mouse movement, or scroll depth.

Telemetry is fail-open: a Redis outage drops events silently rather than blocking user actions. Detailed schema and retention policy are documented in docs/TELEMETRY_GOVERNANCE.md.

Vulnerability disclosure

We follow coordinated disclosure. Security reports go to [email protected] or via private GitHub Security Advisory. We acknowledge within 2 business days and respond substantively within 7. Reporters are credited in resulting advisories, with permission.

What we do not yet certify

SOC 2 Type II
In progress with external auditor. Type I evidence available under NDA.
ISO 27001
Not certified. Many underlying controls are documented.
HIPAA
Not in scope. Platform does not process PHI.
PCI DSS
Not in scope. Platform does not process cardholder data.
FedRAMP
Not planned today.
BYOK / Customer-managed KMS
Platform-managed KMS today. BYOK on roadmap.

Stating these gaps directly is part of the trust posture. Pretending to certifications we don't have would be the larger problem.

Verifying these claims

The public OSS frontend repository contains the BFF middleware, session signing, tenant boundary, and audit logging code. Most claims on this page can be verified by reading lib/auth.ts, middleware.ts, and the docs under docs/.

For enterprise customers, we provide a full security review pack covering the threat model, control mappings, and the security architecture in detail. Request via contact.