Security Overview

RevKeen is built with security as a foundational requirement, not an afterthought. Every layer of the platform -- from infrastructure to application logic -- is designed to protect your data and your customers' data.

Security Philosophy

RevKeen follows three core security principles:

1. Defense in depth -- Multiple independent layers of protection ensure that no single failure compromises your data.
2. Least privilege -- Every component, service, and database role operates with the minimum permissions required.
3. Tenant isolation by default -- Your data is logically separated from every other merchant on the platform at the database level.

Infrastructure Overview

RevKeen runs on industry-standard cloud infrastructure with encryption enforced at every boundary.

Encryption

• At rest -- All databases, backups, and object storage are encrypted using AES-256.
• In transit -- All connections use TLS 1.2 or higher. Internal service-to-service communication is encrypted.
• Secrets -- API keys, gateway credentials, and sensitive configuration are stored in Infisical with envelope encryption. They are never committed to source control or exposed in logs.

Tenant Isolation via Row Level Security

RevKeen uses PostgreSQL Row Level Security (RLS) to enforce strict tenant isolation at the database layer. This means that even if application code contains a bug, one merchant's data cannot leak to another.

Every query that touches merchant-scoped data runs through RLS policies that filter rows by merchant_id. This is enforced by the database engine itself -- not by application-layer filtering.

• Runtime role -- API requests execute as revkeen_runtime, which can only access rows matching the authenticated merchant's ID.
• System role -- Cross-tenant operations (such as scheduled jobs) execute as revkeen_system with explicit full-access policies and audit logging.
• Silent deny -- If the merchant context is missing or incorrect, queries return zero rows rather than raising errors. This eliminates data leakage even in edge cases.

For developers building integrations, this means your API keys and tokens are scoped to your merchant account. There is no way to access another merchant's data through the API.

Security Audits

RevKeen conducts regular security reviews across the platform:

• Dependency scanning -- Automated vulnerability scanning on every pull request via GitHub Actions.
• Infrastructure review -- Periodic review of AWS IAM policies, network ACLs, and security group configurations.
• Code review -- All changes to authentication, authorization, and payment flows require review before merging.
• Database policy audits -- RLS policies are verified against the production schema to detect drift or missing coverage.

Responsible Disclosure

If you discover a security vulnerability in RevKeen, we want to hear from you. Please report it responsibly:

• Email security@revkeen.com with a description of the vulnerability.
• Include steps to reproduce the issue if possible.
• Do not publicly disclose the vulnerability until we have had a chance to investigate and deploy a fix.
• We commit to acknowledging reports within 48 hours and providing a resolution timeline within 5 business days.

We do not pursue legal action against researchers who follow responsible disclosure practices.

SOC 2 Compliance Roadmap

RevKeen is working toward SOC 2 Type II certification. Our current progress:

We will update this page as we reach each milestone. If you have specific compliance questions or need documentation for your own audits, contact support@revkeen.com.