Security overview
The architecture, controls, and operational practices that protect customer data inside Koji enterprise deployments. Written for security architects, CISOs, and the InfoSec teams completing vendor security questionnaires.
Infrastructure
Koji runs on two SOC 2 Type II-attested cloud platforms: Vercel for the application layer and Supabase for the database, authentication, and storage layers. Both platforms operate from major cloud providers (AWS, Google Cloud) with multiple availability zones and the physical security, environmental controls, and operational certifications that come with them.
Koji does not operate any of its own data centers or physical servers. All compute and storage runs on these managed cloud platforms.
Isolation per enterprise client
Every enterprise customer is provisioned a dedicated, isolated database instance. Customer data never sits in a shared table or shared schema with another customer's data. The isolation is at the database level, not just at the row level, which means even a hypothetical misconfiguration of application-layer access controls cannot expose data across customer boundaries.
Regional deployment
Enterprise deployments are provisioned in the region the customer selects at contract signing: European Union or United States. The choice applies to the application layer, the database, the file storage, and the observability pipeline. Once provisioned, data does not transit through the other region in the normal course of operations.
Encryption
- In transit: TLS 1.2 or higher for all client and server-to-server communication. HSTS enforced for the application. Certificate management is automatic via the cloud platforms.
- At rest: AES-256 encryption for all stored data, including the database, file storage, and backups.
- Backups: Encrypted at rest and isolated to the customer's region.
- Application secrets: Stored in the cloud platforms' secret managers, encrypted at rest, accessible only to the running application.
- Customer LLM keys (when applicable): When a customer brings their own enterprise LLM keys, those keys are stored encrypted at rest using envelope encryption and never logged in cleartext.
Access controls
Customer-side access
- SSO via SAML is the default authentication method for enterprise deployments, with support for the major identity providers (Okta, Microsoft Entra/Azure AD, Google Workspace, OneLogin, JumpCloud).
- SCIM provisioning is supported, so user lifecycle (joiners, movers, leavers) follows the customer's identity-provider source of truth.
- Role-based access control at the team level (owner, admin, member) with the principle of least privilege.
- Subdomain isolation: Each enterprise customer accesses the platform at their own subdomain (yourcompany.koji.so), which provides an additional logical boundary.
Koji-personnel access
- Access to production systems is restricted to a defined set of named engineers under the principle of least privilege.
- All Koji personnel are required to authenticate with SSO and multi-factor authentication to any system that touches production.
- Access to customer databases is logged. Routine engineering work does not require customer-data access; debugging requests are handled through scoped, time-bound access grants approved by a second engineer.
- All Koji personnel are bound by confidentiality obligations. Security awareness training is required on an annual cadence per Koji's documented security policy.
- Access is reviewed on a quarterly cadence per documented policy; revocation is immediate on role change or departure.
Application security
- Authentication: SAML SSO for enterprise; for internal Koji tools, mandatory SSO with MFA.
- Authorization: Database-level row security policies (Supabase RLS) enforce that every read and write is scoped to the authenticated tenant and team.
- Input validation: Server-side schema validation (Zod) on every API endpoint. No unsafe SQL composition; all database access goes through the Supabase client which parameterizes queries.
- API rate limiting: Applied at the edge and at the application layer for public endpoints.
- Dependency management: Automated vulnerability scanning of NPM dependencies on every pull request; security patches applied promptly.
- Secret detection: Pre-commit and CI scanning prevent credentials from being committed to the repository.
Logging, monitoring, and audit
- Application logs: Structured logs from the application and edge layers, with PII minimized at log time and retained for the period defined in the customer DPA.
- Distributed tracing: Vercel OTel integration provides end-to-end request traces for debugging and performance monitoring.
- Database audit logs: All administrative actions against the database are logged with actor, time, and target row identifiers. Logs are retained for the period specified in the customer's contract; six-year retention is available for healthcare deployments.
- Authentication audit logs: Every successful and failed authentication event is logged.
- Alerting: Critical errors and security events fire alerts to the on-call engineer within minutes.
Software development lifecycle
- All code changes go through peer code review before merging to the main branch.
- Automated CI runs type checks, linting, and tests on every pull request.
- Deployments are continuous from the main branch; rollback is available within one minute.
- Database schema changes are applied through versioned migration files reviewed before application.
- Production access requires explicit elevation and is logged.
Penetration testing
Independent third-party penetration testing is scoped on an annual cadence alongside Koji's SOC 2 audit engagement, with additional targeted tests after major architectural changes. Where a redacted summary of a prior engagement is available, it is released under NDA on request to [email protected]. When the next scheduled engagement is still in progress, we share the expected publication window in the same response.
Business continuity and disaster recovery
- Backup cadence: Continuous incremental backups via the database provider, with point-in-time recovery available within the customer's contracted region.
- Recovery objectives: Operational target of Recovery Time Objective (RTO) four hours, Recovery Point Objective (RPO) one hour for the production system. Enterprise contracts can specify tighter objectives where required.
- Geographic redundancy: Multi-AZ deployment within the selected region. Cross-region replication available on request as part of the enterprise contract.
Incident response
Koji's incident response process is documented and exercised. See the incident response page for the detection-to-notification flow and the customer notification commitments in the DPA.
Vulnerability disclosure
Security researchers and customers can report vulnerabilities responsibly through our vulnerability disclosure policy. We acknowledge reports within one business day and operate a published safe-harbor commitment for good-faith research.
Certifications and attestations
- SOC 2 Type II: On Koji's compliance roadmap. See SOC 2 status for the current phase and target audit period.
- ISO/IEC 27001: On Koji's compliance roadmap, scoped alongside SOC 2. See ISO 27001 status for the Annex A control mapping and target timeline.
- Upstream attestations inherited from our platforms: Vercel and Supabase both hold current SOC 2 Type II attestations. AWS and Google Cloud (the underlying infrastructure) hold ISO 27001, SOC 2 Type II, PCI DSS, and a wide range of additional attestations.
- ISO 42001 (AI management systems): Aligned with the standard's clauses and Annex A controls. Certification scoped on the longer-term roadmap. See AI governance.
Want the detailed answers?
A pre-filled CAIQ Lite security questionnaire is available for download on the resources page. For full-length CAIQ, SIG, or custom security questionnaires, email [email protected] and a completed response is typically returned within five business days.