Operalta

This document describes Operalta's security architecture, controls, and commitments in detail. It supplements our Terms of Service and Privacy Policy.

1. Data Encryption

1.1 Encryption in Transit

Production traffic is served over HTTPS with modern TLS
HSTS is enabled on production responses
Transport-level protections are applied at the edge and application layers

1.2 Encryption at Rest

Database and storage layers rely on provider-managed encryption at rest
Backups inherit provider-managed encryption and retention controls
Access to stored data is mediated through authenticated application flows

1.3 Sensitive Credential Handling

Beyond provider-managed encryption, sensitive credentials are handled through protected backend flows and are not exposed to the browser by default.

API keys, OAuth tokens, and integration credentials are created and managed through authenticated server-side paths
Credential access is restricted to the backend codepaths that need them
Rotation and revocation are supported on the relevant key and integration surfaces
Additional hardening can vary by provider and data category

2. Authentication & Access Control

2.1 Password Security

Passwords are hashed with bcrypt through our identity stack
Minimum 8 characters required
Passwords are never stored in plaintext, logged, or transmitted unencrypted

2.2 Multi-Factor Authentication (MFA)

SMS-based OTP through a managed messaging provider
6-digit codes with 10-minute expiry
Required for sensitive operations (password reset with MFA enabled)
Session binding to prevent token replay attacks
OTP codes are hashed (SHA-256) before storage

2.3 Session Management

JWT-based sessions with automatic refresh token rotation
Tokens stored in HTTP-only, Secure, SameSite cookies
7-day session expiry with refresh
Automatic session invalidation on password change

2.4 Row-Level Security (RLS)

Database policies are a core part of our isolation model, but they are not the only control. Company-scoped product data is protected by a combination of database policies, route-level access checks, and tightly constrained elevated backend flows.

Company-scoped product tables are expected to ship with database policy coverage and scoped route checks
Policies enforce company_id scoping for company-scoped reads and writes where applicable
Internal tools use scoped clients by default
Elevated service-role flows are reserved for backend jobs and require validated identifiers or prior scoped resolution
New sensitive tables and functions are reviewed for policy coverage before deployment

2.5 Role-Based Access Control (RBAC)

Beyond row-level isolation, role and context checks ensure that each user can only perform actions permitted within the company context they actually hold.

Role templates vary by company context and are mapped to scoped permissions
Write policies use SECURITY DEFINER functions (is_company_member_with_role()) to prevent RLS recursion
Role checks enforced at both the API layer (middleware) and database layer (policies)
Role assignment at invitation — cannot be self-elevated
Administrative actions are logged for audit and compliance

3. Attack Prevention

3.1 Brute Force Protection

Redis-based rate limiting on all authentication endpoints
Password reset: 5 requests per 15 minutes per email
OTP send: 3 requests per 5 minutes per phone number
OTP verify: 10 attempts per 5 minutes + 3 attempts per code (DB-level)
Chat API: 40 requests per minute per user

3.2 Timing Attack Prevention

Constant-time comparison for OTP verification (timingSafeEqual)
OTP codes hashed with SHA-256 before database storage

3.3 CSRF Protection

SameSite=Lax cookies by default
Same-origin policy enforced
API routes validate session tokens on every request

3.4 Input Validation

Schema validation with Zod on all API endpoints
XSS prevention via React's automatic output escaping
SQL injection prevention via parameterized queries and typed database access layers
Input sanitization for user-generated content

3.5 Rate Limiting Failure Mode

Security-critical routes (authentication, token endpoints) operate in a fail-closed mode: if the rate-limit store is unavailable, requests return 503 Service Unavailable rather than passing through without rate limiting.

4. Infrastructure Security

Hosting & Delivery Infrastructure

DDoS protection and Web Application Firewall (WAF)
Provider-managed platform patching and infrastructure maintenance
Edge and delivery infrastructure can operate across supported regions
Core infrastructure providers maintain SOC 2 Type II attestations or equivalent audits

Data Infrastructure

Data stored in eu-central-2 (Zurich, Switzerland)
Managed network controls and provider security boundaries
Automated daily backups with point-in-time recovery
Core data infrastructure providers maintain SOC 2 Type II attestations or equivalent audits

Rate Limiting & Abuse Controls

Distributed rate limiting across edge locations
EU region (Frankfurt)
Fail-closed on security-critical routes

Monitoring & Incident Response

Automated monitoring and alerting on critical paths
Dependency scanning and patch review as part of the security process
Incident response workflows include applicable breach-notification obligations
Security reviews and hardening are performed continuously on sensitive surfaces

5. AI Agent Security

Selected Operalta agent and automation surfaces can access files, run commands, and fetch external content on your behalf. These capabilities are sandboxed and controlled, and they inherit the same company-bound access model as the rest of the platform.

5.1 Agent Data Isolation (RLS + RBAC)

Agent context assembly (memory, artifacts, conversations, metrics) stays company-scoped
Sub-agent orchestration resolves slug/ID through RLS client before any service-client fallback
Agent-initiated writes use the same shared helpers and permission checks as product writes
Elevated backend helpers remain constrained to validated server-side flows

5.2 File System Sandbox

Agent file access is restricted to explicitly scoped directories
Path traversal attempts (e.g., ../../) are blocked at validation
Symbolic link escapes are detected and rejected

5.3 Shell Isolation

Execution environments are constrained and do not expose the full server secret set to subprocesses
Execution time and permissions are capped server-side regardless of what the agent requests
High-risk operations require approval or are denied by default

5.4 SSRF Protection

Protected web-fetch surfaces block private IP ranges, loopback addresses, and metadata endpoints
Connection-time checks reduce DNS rebinding and destination-switch attacks on guarded fetch paths
Network controls vary by surface, with stricter policies on high-risk fetch and ingestion flows

5.5 Human-in-the-Loop

Sensitive operations require explicit user approval before execution
Unknown or unrecognized tool calls are denied by default
Users maintain full control over which integrations are enabled

5.6 AI Provider Data Handling

Approved AI providers and managed model routes are covered by contracts, DPAs, or provider terms where applicable
Customer data is not used to train third-party models
Provider retention and logging behavior follow the relevant provider terms and configured account settings
Model invocation logging is disabled where configured on supported managed inference paths

6. Compliance & Privacy

GDPR

Processor terms, DPAs, and transfer safeguards are maintained where applicable
Right to access, rectification, and erasure
Data portability (JSON/CSV export)
Breach notification workflows follow GDPR timing and legal requirements

CCPA

Right to know what data is collected
Right to delete personal information
Right to opt out of sale (we never sell data)
Non-discrimination for exercising rights

Data Retention

Active accounts: Data is retained while the account remains active, subject to documented retention schedules
Deleted accounts: Export and deletion timing follows the Privacy Policy, Security Terms, applicable law, and any valid legal hold
Backups: Backup purge follows documented operational retention windows
Audit logs: Selected audit and compliance logs may be retained longer where legally required
AI providers: Provider retention and processing obligations follow their terms and DPAs; customer data is not used to train third-party models

For exact deletion windows, request timelines, and backup treatment, refer to our Privacy Policy and the applicable account or request workflow.

SOC 2 Type II: Operalta SOC 2 Type II certification is currently in progress. Core infrastructure providers maintain independent SOC 2 Type II certifications or equivalent audits.

No data selling: We never sell your data. Approved AI providers do not use your data to train third-party models. Provider retention and logging behavior follow their contracts, DPAs, and published terms.

7. Security Practices

Development Practices

Code review is expected for product changes
Dependency scanning and patch review are part of the security process
TypeScript strict mode — compile-time type safety across the entire codebase
ESLint strict configuration — zero-warning policy enforced at build time

Secrets Management

Sensitive secrets are kept out of source control and stored in environment or provider-managed secret stores
Integration credentials (API keys, OAuth tokens) are handled through protected backend flows
Least-privilege access is applied to internal team members and service accounts
Production and development environments use separate configuration and secret material

Error Handling

Security-focused error handling — no sensitive data in error messages or stack traces
Generic error responses for authentication failures (no user enumeration)
Server-side logging for diagnostics, separate from client-facing responses

8. Responsible Disclosure

If you believe you have found a security vulnerability in Operalta, please report it to us immediately.

Email: security@operalta.com

Please include detailed steps to reproduce the vulnerability, including the affected URL, request/response details, and any proof-of-concept code. We commit to acknowledging reports within 48 hours and working with security researchers to resolve issues quickly.

We appreciate responsible disclosure and will not take legal action against researchers who report vulnerabilities in good faith and comply with these guidelines:

Do not access, modify, or delete data belonging to other users
Do not disrupt service availability (no DoS testing)
Report findings to us before disclosing publicly
Allow reasonable time for remediation before public disclosure

For questions about our security practices, contact security@operalta.com

Security overview · Terms of Service · Privacy Policy

Sub-processor information is available on request via privacy@operalta.com.

Security Terms