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
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
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.