SECURITY
Security at RANKIGI
We hold ourselves to the same standards we provide to our customers. RANKIGI is built from the ground up to be tamper-evident, cryptographically verifiable, and independently auditable.
Data Architecture
RANKIGI never stores raw agent inputs or outputs. Every event payload is SHA-256 hashed before ingestion — we store only the resulting hash, a canonical representation of the payload, and minimal metadata (agent ID, action type, timestamp, tool invoked, severity level). Your sensitive data never touches our storage layer. The canonical payload is a deterministic JSON representation with sorted keys (max 10 levels of nesting) used exclusively for hash computation and chain verification.
Infrastructure Security
Hosting: The RANKIGI platform is hosted on Railway, a deployment platform built on top of major cloud providers. All infrastructure runs in US-based regions by default, with EU residency available for Enterprise customers.
Database: Supabase (Postgres 16) with row-level security (RLS) enforced at the database layer. Every query is scoped by organization — there is no cross-tenant data access path. All database connections use TLS.
Encryption: All data is encrypted in transit using TLS 1.3. Data at rest is encrypted using AES-256 via our infrastructure provider. API keys are peppered and hashed (SHA-256) before storage — we cannot retrieve your raw API key after creation.
Access Controls
RANKIGI enforces role-based access control (RBAC) at every endpoint:
Admin — Full access. Register agents, manage API keys, create policies, generate reports, run snapshots.
Auditor — Read and verify. View events, verify chain integrity, generate reports, run snapshots. Cannot create agents or manage keys.
Read-only — Query event timelines only. Cannot verify chains or generate reports.
API authentication uses Bearer token (ingest API key) with peppered hash verification. Dashboard authentication uses Supabase Auth with JWT-based session cookies. Organization membership is resolved via the org_members table before any data access.
Immutability
The event audit trail is append-only by design. Database-level triggers prevent UPDATE and DELETE operations on the event_hash_chain table. These triggers are enforced at the Postgres layer — they cannot be bypassed by application code.
Every event is SHA-256 hashed and cryptographically chained to the previous event via the formula:hash = SHA-256(prev_hash | occurred_at | org_id | agent_id | canonical_payload)
Any modification to any past event immediately breaks the chain. Chain integrity can be verified at any time via the API or dashboard.
Vulnerability Disclosure
We welcome responsible security research. If you discover a vulnerability in the RANKIGI platform, please report it to: security@rankigi.com
We commit to: acknowledging reports within 48 hours; providing a resolution timeline within 5 business days; not pursuing legal action against researchers acting in good faith; and crediting researchers who report valid vulnerabilities (with consent).
SOC 2 Type II
SOC 2 Type II certification is in progress. We are targeting completion by Q4 2026. The audit covers the Trust Service Criteria for Security, Availability, and Confidentiality. Enterprise customers can request our current security documentation, architecture diagrams, and third-party assessment results under NDA.
Penetration Testing
Annual third-party penetration testing is scheduled for Q3 2026. The scope will cover the full RANKIGI attack surface: REST API endpoints, SDK libraries, dashboard application, authentication flows, and infrastructure configuration. Results will be available to Enterprise customers under NDA.
Bug Bounty
A formal bug bounty program is planned for launch after the completion of our first penetration test (Q3 2026). In the meantime, please report any security concerns to security@rankigi.com.