Security Policy

The OpenAgent Core web application and API are hosted on Vercel, a SOC 2 Type II certified platform. Vercel provides automatic TLS certificate provisioning, DDoS mitigation at the edge, and globally distributed deployment.

All persistent data is stored in Supabase-managed PostgreSQL instances. Supabase is SOC 2 Type II certified and operates dedicated, isolated database instances per project. Physical access to database servers is controlled by AWS (us-east-1 region by default), which maintains ISO 27001, SOC 1/2/3, and PCI DSS certifications.

• All traffic between clients and our platform is encrypted using TLS 1.2 or higher. TLS 1.0 and 1.1 are disabled.
• HTTP requests are automatically redirected to HTTPS. HTTP Strict Transport Security (HSTS) is enforced with a minimum max-age of 31,536,000 seconds.
• Database connections from the application layer to Supabase use encrypted channels with certificate validation.
• Internal service communication is restricted by IP allowlists and environment-scoped API keys.

Production, staging, and development environments are strictly separated. Production credentials are never used in lower environments. Environment variables are managed as secrets and are never committed to source control.

Platform API keys (the keys we issue to your tenant) are processed as follows:

• A cryptographically random 32-byte key is generated server-side using crypto.randomBytes(32).
• The plain-text key is returned to you exactly once at generation time via a secure TLS connection and is never stored or logged by us.
• A unique 16-byte random salt is generated per key.
• The key is hashed using PBKDF2-SHA256 with 600,000 iterations — the OWASP 2024 recommended minimum — producing a 256-bit derived key.
• Only the hash and salt are persisted in the database. Even in the event of a full database compromise, recovering plain-text keys from these hashes is computationally infeasible.
• All hash comparisons use constant-time equality (crypto.timingSafeEqual) to prevent timing side-channel attacks.

Basiq.io API keys that you supply to the platform are encrypted before storage:

• Encryption uses AES-256-GCM (Galois/Counter Mode), which provides both confidentiality and authenticated integrity.
• A unique 12-byte Initialisation Vector (IV) is generated per encryption operation. IV reuse is prevented by construction.
• The encryption key is derived from a server-side secret (API_ENCRYPTION_KEY) that is stored as an environment secret and never committed to code.
• The GCM authentication tag is verified on every decryption operation; tampered ciphertext will fail decryption and be rejected.
• Decryption occurs only at the point of an authorised API call and the plain-text key is held in memory for the minimum time necessary.

• All external API traffic uses TLS 1.2+ with strong cipher suites (ECDHE key exchange, AES-GCM or ChaCha20-Poly1305 symmetric encryption).
• Outbound calls to Basiq.io and Stripe are made over verified TLS connections with certificate chain validation.
• No sensitive data is transmitted via query parameters or URL fragments.

• All secrets (database URLs, encryption keys, Stripe secrets, Supabase service role keys) are stored as environment secrets in Vercel and are never hardcoded in source files.
• Secrets are rotated on a scheduled basis and immediately upon any suspected compromise.
• The .env.local file is excluded from version control via .gitignore.

• All tables in the database have Row Level Security enabled at the PostgreSQL level.
• RLS policies enforce that every SELECT, INSERT, UPDATE, and DELETE operation is automatically scoped to the authenticated tenant's ID, derived from the verified JWT claim.
• It is architecturally impossible for an authenticated tenant to read, write, or delete another tenant's data — even if application-level filtering is absent.
• Service-role operations that bypass RLS (e.g., administrative tasks) are performed only with the Supabase service role key, which is never exposed client-side.

All tenant-scoped columns (tenant_id, user_id) are indexed. This prevents full-table scans from being used as a vector to enumerate cross-tenant data through timing differences.

• The anon key is used for all client-side operations and is safe to be public — it enforces RLS.
• The service role key bypasses RLS and is used exclusively in server-side code. It is never included in client bundles or API responses.

• User authentication is handled by Supabase Auth, which supports email/password (with bcrypt password hashing), and OAuth providers (GitHub, Google).
• Sessions are managed via secure, HttpOnly, SameSite=Lax cookies. Session tokens are never stored in localStorage.
• Supabase Auth enforces email verification for new registrations.
• Password reset flows use single-use, time-limited tokens delivered via email.

• Programmatic API access uses tenant API keys issued by the platform.
• Keys follow the format sk_{tenantId_prefix}_{random_base64url}, providing both tenant attribution and sufficient entropy.
• Keys must be transmitted in the Authorization: Bearer header over TLS. Keys in URL query strings are rejected.
• Failed authentication attempts are rate-limited to prevent brute-force enumeration.

All internal service accounts, database roles, and API integrations are granted only the minimum permissions required for their function. Access rights are reviewed periodically and revoked when no longer needed.

All user-supplied inputs are validated using Zod schemas on both the client and server. Server-side validation is always enforced, independent of client-side checks. Inputs exceeding defined length or type constraints are rejected before reaching business logic.

All inbound webhooks from Stripe are verified using HMAC-SHA256 signature validation before any payload is processed. Requests with invalid or missing signatures return a 400 Bad Request and are not processed. Verified event IDs are stored to ensure idempotent processing and prevent replay attacks.

The following HTTP security headers are applied to all responses:

• Strict-Transport-Security — HSTS with preload
• X-Content-Type-Options: nosniff
• X-Frame-Options: DENY
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy — camera, microphone, geolocation disabled
• Content-Security-Policy — restricts script sources to self and trusted CDNs

• All third-party dependencies are pinned to specific versions in package-lock.json.
• Automated dependency scanning runs on every pull request via npm audit.
• Critical and high severity CVEs are patched within 7 days. Medium severity within 30 days.

• Production database access requires multi-factor authentication (MFA).
• Access to production systems is restricted to named individuals with a documented need.
• All access is logged and reviewed periodically. Terminated employees have access revoked on the day of departure.

The following events are logged with timestamps, tenant context, IP addresses, and outcomes:

• Authentication successes and failures (login, API key validation)
• API key generation, rotation, and revocation
• All MCP tool invocations and Basiq API calls
• Subscription plan changes and billing events
• Administrative actions on tenant accounts
• Rate limit threshold breaches

Logs are retained for 90 days and are stored separately from the primary database to prevent tampering.

We operate 24/7 monitoring for:

• Service availability and latency (p50, p95, p99)
• Abnormal authentication failure rates
• Unusual API usage spikes that may indicate compromise
• Database query anomalies
• Third-party service status (Basiq.io, Stripe, Supabase, Vercel)

Automated alerts are routed to on-call engineers for immediate response.

• All code changes undergo peer review before merging to the production branch.
• Security-relevant changes require explicit sign-off from a senior engineer.
• TypeScript strict mode is enforced across the entire codebase to catch type-related vulnerabilities at compile time.
• Secrets scanning is run on every commit to prevent accidental credential exposure.

• Database backups are performed daily with point-in-time recovery (PITR) enabled.
• Backups are encrypted at rest and stored in a separate availability zone.
• Recovery procedures are tested quarterly. Our Recovery Time Objective (RTO) is 4 hours; our Recovery Point Objective (RPO) is 24 hours.

When a security incident is detected or reported, we follow a structured response process:

1. Triage (within 2 hours) — Assess severity, scope, and affected tenants.
2. Containment (within 4 hours for critical) — Isolate affected systems, revoke compromised credentials, block attack vectors.
3. Eradication — Identify and eliminate the root cause.
4. Recovery — Restore services from clean state. Verify integrity before returning to production.
5. Post-Incident Review — Document timeline, root cause, and remediation actions. Update controls to prevent recurrence.

If a security incident results in unauthorised access to your data, we will:

• Notify you by email to your registered address within 72 hours of confirming the breach — in line with the Notifiable Data Breaches (NDB) scheme under the Privacy Act 1988 (Cth).
• Provide details of what data was affected, the likely cause, and the steps we have taken.
• Work with you on any required notifications to your End Users or regulators.
• Notify the Office of the Australian Information Commissioner (OAIC) as required by the NDB scheme.

If you suspect your API Key has been compromised:

• Revoke the key immediately via the Settings page in your dashboard.
• Generate a new key and update all integrations.
• Contact security@thinkfoundry.ai so we can review access logs for signs of unauthorised use.

Please send vulnerability reports to security@thinkfoundry.ai with:

• A clear description of the vulnerability and the affected component.
• Steps to reproduce (including HTTP requests, payloads, or proof-of-concept code where relevant).
• The potential impact if exploited.
• Your contact details for follow-up.

Please encrypt sensitive reports using our PGP key, available on request.

• Acknowledgement — We will acknowledge receipt within 24 hours.
• Triage — We will provide an initial severity assessment within 5 business days.
• Resolution — We aim to resolve critical vulnerabilities within 7 days, high within 30 days, and medium/low within 90 days.
• No legal action — We will not pursue legal action against researchers who disclose vulnerabilities responsibly under these guidelines.
• Credit — With your permission, we will publicly acknowledge your contribution once the vulnerability is resolved.

In scope for disclosure:

• Authentication and authorisation vulnerabilities
• Data isolation failures between tenants
• API key exposure or bypass
• Injection vulnerabilities (SQL, command, etc.)
• Sensitive data exposure
• CSRF and XSS on the dashboard

Out of scope:

• Vulnerabilities in third-party services (Basiq.io, Stripe, Supabase) — report those directly to the vendor
• Denial of service attacks
• Social engineering or phishing of our employees
• Issues requiring physical access to our infrastructure

• Never expose API keys client-side. Keys must only be used in server-side code (API routes, server components, or backend services).
• Never commit keys to source control. Use .env.local or your hosting provider's secrets management.
• Rotate keys periodically — at minimum every 90 days for production applications.
• Revoke unused keys immediately. Each integration should have its own key to enable precise revocation.
• Monitor your usage dashboard for unexpected spikes that may indicate key leakage.

• Do not store CDR consumer data beyond the minimum period necessary for your application's stated purpose.
• Encrypt any Financial Data you persist in your own database.
• Implement your own RLS or equivalent tenant-isolation controls if you build multi-tenant applications on top of our platform.
• Provide your End Users with a clear consent and privacy notice before requesting access to their financial data.

• All calls to the OpenAgent Core API must be made over HTTPS. HTTP requests will be rejected.
• Validate TLS certificates in your HTTP client. Do not disable certificate validation in production.