Security Statement

Last Updated: April 7, 2026

1. Row-Level Data Isolation

Every database table is protected by row-level security (RLS) policies. Your assessment data, findings, credentials, and reports are isolated to your team — no other user or team can access them, even at the database level. Policies are enforced by PostgreSQL itself, not application code, eliminating an entire class of access-control bugs.

2. Credential Encryption

LLM API keys, MCP server authentication tokens, and assessment credentials are encrypted at rest in the database. Keys are never exposed in API responses or client-side code. All communication between the client and backend occurs over TLS 1.2+.

3. Role-Based Access Control

Team access is governed by a dedicated roles system (Owner, Admin, Member) stored in a separate security table with a SECURITY DEFINER function — preventing privilege escalation via client-side manipulation. Role checks are enforced server-side on every protected operation.

4. Login & Activity Auditing

Every sign-in event is logged with IP address, browser fingerprint, and geolocated city/region/country. Team activity (assessments created, members invited, settings changed) is tracked in a dedicated audit log. All audit data is available to team administrators in the dashboard.

5. Assessment Scope Enforcement

The AI assessment engine enforces scope boundaries in real time. Every tool call is validated against the defined scope before execution. DNS-resolved aliases of in-scope targets are automatically tracked to prevent false scope violations, while genuinely out-of-scope targets are blocked. Tool outputs are sanitized to strip noisy or irrelevant data before processing.

6. Proprietary Methodology Protection

Assessment methodology prompts — including continuation strategies, phase transitions, and reasoning triggers — are injected server-side within edge functions. They are never included in API responses to the client. Even authenticated users inspecting network traffic will see only generic action flags and trigger IDs, ensuring zero methodology leakage.

7. Infrastructure & Compliance

Phantava is built on Supabase, which provides SOC 2 Type II certified infrastructure, automated backups, and encryption at rest and in transit.

we undergo an annual CIS Critical Security Controls (CSC) audit, ensuring our organizational security practices are independently validated against industry-recognized benchmarks.

8. Authentication & MFA

Account registration requires email verification. Passwords are hashed using bcrypt via Supabase Auth. Password reset flows use time-limited, single-use tokens. Team invitations use cryptographically random tokens with configurable expiration.

Phantava supports TOTP-based multifactor authentication (MFA). When enabled, users must provide a one-time code from an authenticator app (such as Google Authenticator, Authy, or 1Password) at each sign-in — adding a critical second layer of defense against credential compromise.

9. Contact

Have a security concern? Contact us at security@phantava.com.