Truvyx

Security

Last updated: June 28, 2026

Overview

Security is a core design principle at Truvyx. We handle evaluation data, agent configurations, and audit records that organisations treat as sensitive intellectual property. This page describes the technical and operational controls we have in place to protect your data and the integrity of the platform.

If you discover a potential security vulnerability, please report it immediately to security@truvyx.com. Do not disclose vulnerabilities publicly until we have had a reasonable opportunity to investigate and remediate. See the Responsible Disclosure section below.

1. Infrastructure Security

Truvyx is hosted on Vercel (application and serverless functions) and Neon (PostgreSQL database). Both providers hold SOC 2 Type II certifications, meaning their infrastructure controls are independently audited on an ongoing basis.

  • Physical security: Our infrastructure runs in ISO 27001-certified data centres operated by Vercel and Neon's cloud providers (AWS). Physical access is restricted to authorised personnel only and is logged and monitored.
  • Network segmentation: Database instances are not publicly accessible. All database connections are made from within the serverless function runtime over TLS-encrypted private connections. No direct public internet access to the database is permitted.
  • DDoS protection: Vercel's edge network provides DDoS mitigation for all incoming traffic to the application.
  • Serverless isolation: Application logic runs in isolated, short-lived serverless function instances. There is no persistent process state shared between requests, reducing the blast radius of any single compromised execution.

2. Data Encryption

  • In transit: All communication between clients and the Truvyx platform uses TLS 1.2 or higher. HTTP requests are automatically redirected to HTTPS. TLS certificates are automatically provisioned and renewed by Vercel via Let's Encrypt.
  • At rest: The Neon PostgreSQL database is encrypted at rest using AES-256 by the underlying cloud storage provider. Vercel's serverless infrastructure also encrypts stored data at rest.
  • Session tokens: Authentication session tokens (JWTs) are encrypted using AES-256-CBC-HMAC-SHA512 (JWE, A256CBC-HS512) with a key derived from the application's AUTH_SECRET environment variable via HKDF-SHA256. The token is stored in an HttpOnly; Secure; SameSite=Lax cookie and is never accessible from JavaScript.
  • Passwords: Credentials-based account passwords are hashed using bcrypt with a cost factor of 10. Raw passwords are never logged, stored, or transmitted after the initial hash computation.
  • API keys: API keys are generated with a cryptographically secure random generator and stored as SHA-256 hashes. The raw key value is shown only once at creation time and cannot be retrieved afterwards. Lost keys must be rotated.
  • Audit record signing: Signed audit records use asymmetric cryptography. The signing process produces a verifiable signature tied to the record content. Tampering with a signed record is detectable by any party with the public verification key.

3. Authentication and Identity

  • OAuth 2.0: Sign-in with Google and GitHub uses the OAuth 2.0 authorisation code flow. Truvyx never receives your password for these providers. We receive only the minimum profile data (email, name, avatar) required to create your account.
  • CSRF protection: All mutating API endpoints and form submissions are protected against Cross-Site Request Forgery via token validation on the server.
  • Session management: Sessions expire after 30 days of inactivity. Changing your password invalidates all existing sessions. Deleting your account immediately invalidates all sessions.
  • Brute-force protection: Authentication endpoints are rate-limited to prevent credential stuffing and brute-force attacks. Repeated failed login attempts result in progressive delays and eventual temporary lockout.
  • Account linking: We support safe account linking between OAuth providers (Google/GitHub) and email/password accounts using verified email address matching. Unverified emails are not permitted for linking.

4. Authorisation and Access Control

Truvyx enforces role-based access control (RBAC) at the organisation level. Every resource — scenarios, runs, audit records, API keys, member lists, billing information — is scoped to an organisation. Cross-organisation data access is prevented at the data layer: all database queries include an organizationId predicate, ensuring that even if application logic were bypassed, the database would not return data belonging to a different organisation.

  • OWNER: Full administrative control — manages members, billing, API keys, and all organisational resources.
  • ADMIN: Can create and manage scenarios, runs, and reports. Cannot manage billing or other owners.
  • MEMBER: Can view and use resources created within the organisation. Cannot delete organisational resources or manage other members.

Permission checks are enforced server-side on every request. Client-side UI rendering of permissions is a convenience layer only and does not constitute a security boundary.

5. API Key Security

API keys follow the format trk_… and are issued with organisation-level permissions. Key management best practices:

  • Treat API keys as passwords. Do not commit them to version control, paste them into chat tools, or embed them in client-side code.
  • Use environment variables or secrets management tools (e.g. Vercel Environment Variables, AWS Secrets Manager) to inject API keys at runtime.
  • Rotate API keys immediately if you suspect they have been compromised.
  • Assign each integration its own API key so you can revoke access for a specific integration without affecting others.
  • Truvyx stores only the SHA-256 hash of your API key. If you lose a key, it cannot be recovered — you must create a new one.

6. Application Security

  • Input validation: All API inputs are validated using Zod schema validation on the server before any database operation. Validation errors return structured 422 responses; they are never silently ignored.
  • SQL injection: All database access is mediated through Prisma ORM with parameterised queries. Raw SQL is not used for user-supplied input. Prisma's query builder prevents SQL injection by construction.
  • XSS prevention: The application uses React's automatic output escaping for all rendered content. Dangerously-set HTML is not used except for the advertising pixel initialisation scripts in the root layout, which use environment variable values set at build time (not runtime user input).
  • Content Security Policy: HTTP response headers include a Content-Security Policy to restrict the origins from which scripts, styles, and media may be loaded.
  • Security headers: All responses include X-Frame-Options: DENY, X-Content-Type-Options: nosniff, and Referrer-Policy: strict-origin-when-cross-origin.
  • Dependency management: Dependencies are pinned and audited regularly. We monitor for known vulnerabilities using automated dependency scanning in our CI/CD pipeline. Critical security patches are applied as a priority.

7. Secrets Management

All application secrets (database credentials, authentication secrets, OAuth client secrets, API keys for third-party services) are stored as Vercel Environment Variables and are never committed to version control. Secrets are scoped by environment (development, preview, production) and are not accessible from client-side code.

The AUTH_SECRET used to sign and encrypt session tokens is a 256-bit cryptographically random value generated with openssl rand -base64 32. Rotating this value invalidates all active sessions.

8. Audit Logging and Monitoring

  • Platform audit trail: All evaluation runs, constraint verdicts, RCA analyses, audit record creation and signing events, member changes, API key creation and revocation, and billing events are logged with timestamps and acting user identity.
  • Access logs: Server access logs capture all HTTP requests to the platform, including IP address, HTTP method, path, response status, and latency. These are retained for 90 days.
  • Error monitoring: Application errors and exceptions are captured and monitored. Error events do not include personal data beyond what is necessary to diagnose the error.
  • Security event alerting: Anomalous patterns (such as unusual API key usage volume, repeated authentication failures, or access from unexpected geographies) trigger internal security review.

9. Backup and Recovery

  • Database backups: Neon provides continuous write-ahead log (WAL) archiving with point-in-time recovery (PITR) for up to 7 days on production database instances. Daily snapshots are retained for 30 days.
  • Recovery time: In the event of a database failure, we target a Recovery Time Objective (RTO) of under 4 hours and a Recovery Point Objective (RPO) of under 1 hour, subject to the severity of the incident.
  • Testing: Backup restoration is tested periodically to verify recoverability.

10. Penetration Testing and Vulnerability Management

  • Internal testing: We conduct security reviews as part of our development process, including code review, static analysis, and manual security testing of new features before release.
  • Third-party penetration testing: We plan to commission third-party penetration tests on an annual basis. Summary results are available to enterprise customers under NDA upon request.
  • Vulnerability scanning: Automated dependency and container vulnerability scanning runs on every deployment via our CI/CD pipeline. Critical and high-severity vulnerabilities are remediated within 48 hours of disclosure.
  • OWASP Top 10: Our development practices are aligned with the OWASP Top 10 web application security risks. All developers complete security awareness training before contributing to the production codebase.

11. Incident Response

We maintain an internal incident response procedure that covers:

  • Detection: Security events are detected through automated monitoring, internal security reviews, and responsible disclosure reports.
  • Containment: On confirmation of a security incident, we isolate affected systems, revoke compromised credentials, and prevent further unauthorised access. This typically begins within 1 hour of confirmed detection.
  • Investigation: We conduct a root-cause analysis to determine the scope of the incident, data affected, and how the breach occurred.
  • Notification: We notify affected users and relevant regulators within the timelines required by applicable law (72 hours for GDPR/UK GDPR where the breach poses a risk). Notifications include the nature of the breach, data affected, steps we have taken, and actions you should consider taking.
  • Post-incident review: After resolution, we conduct a post-mortem and implement systemic improvements to prevent recurrence.

To report a suspected security incident: security@truvyx.com.

12. Employee and Contractor Security

  • Access to production systems and customer data is restricted to employees and contractors with a legitimate need.
  • All personnel with production access use unique credentials and, where supported, multi-factor authentication.
  • Access rights are reviewed quarterly and revoked immediately upon role change or departure.
  • Personnel are bound by confidentiality obligations and complete security awareness training before receiving production access.
  • We do not access your organisation's content (scenarios, evaluation data, audit records) unless you have explicitly requested support that requires it, and only after obtaining your consent.

13. Responsible Disclosure

We welcome security researchers who discover vulnerabilities in the Truvyx platform. If you believe you have found a security vulnerability, please:

  1. Email security@truvyx.com with a clear description of the vulnerability, steps to reproduce it, and the potential impact. Encrypt sensitive details using our PGP public key if available.
  2. Do not access, modify, or delete data belonging to other users. Test only against accounts you own or have explicit permission to test.
  3. Do not perform denial-of-service testing, social engineering, or physical security testing without prior written authorisation.
  4. Do not disclose the vulnerability publicly until we have acknowledged it and had a reasonable opportunity to investigate and remediate (typically 90 days).

We will acknowledge receipt of your report within 2 business days, provide updates on our investigation progress, and credit you in our security advisories (unless you prefer anonymity) if the report results in a confirmed fix.

We do not currently operate a formal bug bounty programme with monetary rewards, but we genuinely appreciate responsible disclosures and will acknowledge all valid reports.

14. Compliance Posture

  • GDPR / UK GDPR: We are designed to support our obligations as a data controller under the General Data Protection Regulation and UK GDPR. See our Privacy Policy for full details.
  • CCPA: We support California Consumer Privacy Act rights for California residents.
  • SOC 2: Our primary infrastructure providers (Vercel, Neon) are SOC 2 Type II certified. Truvyx is evaluating SOC 2 Type II certification for the platform itself; enterprise customers can contact us to discuss compliance requirements.
  • Data Processing Agreements: Enterprise customers requiring a Data Processing Agreement (DPA) under GDPR Article 28 may request one at legal@truvyx.com.

Contact

Security enquiries and vulnerability reports: security@truvyx.com
Legal and compliance: legal@truvyx.com
General support: support@truvyx.com