Your most sensitive data can stay on your machine.
The strongest privacy guarantee is where the work runs: your statistics and the notebook's Python execute in your browser, so raw data never reaches our servers. Everything else is layered: encrypted in transit (TLS 1.3) and at rest (AES-256), isolated per researcher by PostgreSQL row-level security, protected by optional two-factor authentication, and recorded in an append-only audit log. Below is exactly what we enforce, and exactly what we don't yet claim.
AES-256
Symmetric encryption standard widely used for encryption at rest by major cloud and database providers.
TLS 1.3
Latest transport encryption protocol, eliminating legacy ciphers and reducing handshake attack surface.
SHA-256
Cryptographic hash from the SHA-2 family, used for recovery-code and integrity hashing through a single FIPS-approved crypto module.
bcrypt
Adaptive password-hashing function resistant to brute-force and GPU-accelerated attacks.
TOTP 2FA
Time-based one-time-password two-factor authentication with single-use recovery codes, enforced fail-closed when enabled.
OWASP ASVS
Application controls aligned to the OWASP Application Security Verification Standard L2 (self-assessed ~92%).
Least Privilege
Access model with every role and policy granting the minimum access required.
Six layers of defense
No single control is a point of failure. An attacker would have to defeat every layer in sequence, and each is independently enforced.
Layer 1
Transport & Edge
Every byte in and out of Olto Discovery is encrypted and filtered at the network edge before it reaches application code.
TLS 1.3 with TLS 1.2 fallback on all connections; HTTP is permanently redirected to HTTPS
HTTP Strict Transport Security (HSTS) enabled with a one-year max-age and includeSubDomains
Global edge network with DDoS absorption and anycast routing through our hosting provider
Rate limiting on authentication, AI, and API endpoints to slow brute-force and abuse
Layer 2
Browser Hardening
A strict set of HTTP security headers constrains what the browser will execute, load, or expose.
Content Security Policy (CSP) restricting scripts, styles, fonts, images, and connections to an explicit allowlist
X-Frame-Options: DENY and frame-ancestors to prevent clickjacking
X-Content-Type-Options: nosniff to block MIME-type confusion attacks
Permissions-Policy disabling camera, microphone, geolocation, USB, and FLoC cohorts
Referrer-Policy: strict-origin-when-cross-origin to limit referrer leakage
Layer 3
Authentication & Sessions
Identity is verified on every request, and credentials are protected with industry-standard cryptography.
Passwords hashed with bcrypt using a per-user salt; plaintext passwords are never stored or logged
Optional two-factor authentication (TOTP) with single-use recovery codes; when enabled, the second factor is enforced before any dashboard or API access — sessions that have not stepped up are redirected to the challenge (fail-closed)
hCaptcha on sign-in and sign-up to slow automated abuse
JWT-based sessions with short-lived access tokens and automatic secure refresh; "sign out everywhere" revokes every active session
Session cookies are Secure and SameSite; a strict Content-Security-Policy and an explicit cross-origin CSRF/Origin check mitigate token theft and request forgery
Per-account session-timeout controls and visible login history for anomaly review
Sign-in records include IP and session and device metadata, surfaced to each user
Layer 4
Authorization & Data Isolation
Even with a valid session, every row of data is gated by database-enforced access policies, not just application logic.
PostgreSQL Row-Level Security (RLS) enforced on every user table: isolation is checked at the database engine, not the app layer
Default-deny posture: tables reject all access unless an explicit policy grants it
Principle of least privilege: the anonymous role can read only explicitly public content
SECURITY DEFINER database functions are pinned to a fixed search_path and revoked from public roles to prevent privilege escalation
Private storage buckets scoped per user; uploads validated by MIME type and size
Layer 5
Encryption at Rest
Stored data is encrypted on disk and in backups using strong, modern ciphers.
AES-256 encryption at rest for the primary database and object storage, provided by our infrastructure platform
Automated backups managed by our database provider; recovery options depend on the provider plan in effect
Secrets and API keys stored in an encrypted environment vault, never committed to source control
Cryptographic operations (hashing, digests) handled by vetted libraries (pgcrypto, bcrypt)
Layer 6
Audit & Accountability
Security-relevant actions are recorded in an append-only audit log that user sessions cannot forge, alter, or delete.
Append-only by design: users can read their own events through a scoped function but cannot insert, alter, or delete entries
Audit entries are written only through a privileged server-side path (service role); a user session has no ability to forge or suppress them
Authentication events, data mutations, and administrative actions are logged with actor, IP, user-agent, and timestamp
Failed-sign-in and rate-limit events are recorded for review of brute-force and credential-stuffing patterns
Audit data is retained and purged on a defined schedule
Compliance posture
Olto Discovery is built on security-conscious infrastructure providers and designed with SOC 2-aligned controls in mind. Olto Discovery has not undergone a SOC 2 audit as of this writing. We rely on infrastructure providers with established security programs, including SOC 2-compliant vendors where available.
HIPAA / PHI: Olto Discovery is not, by default, a HIPAA-covered platform. HIPAA-ready configurations may be available for Enterprise customers under a separate written agreement, where supported by the full vendor and infrastructure stack. Until that agreement is in place, do not upload protected health information.
Restricted data: Unless expressly permitted in a signed Enterprise agreement with an appropriate compliance configuration, do not upload protected health information (PHI), patient-identifiable clinical data, classified information, export-controlled data, controlled unclassified information (CUI), or other regulated sensitive data.
For our framework-by-framework alignment with NIST CSF 2.0, OWASP ASVS Level 2, the NIST 800-series, FIPS 140-3 crypto posture, and CMMC / FedRAMP readiness — stated honestly, including what remains — see the Compliance & Trust page.
Shared responsibility
Olto secures the platform, infrastructure configuration, application controls, and database access policies. Customers are responsible for using strong passwords, enabling two-factor authentication, managing workspace members, removing departed users, configuring visibility settings correctly, and controlling what data they upload.
Olto secures
Platform code, application controls, and configuration
Database access policies and RLS enforcement
Two-factor enforcement, session management, and transport encryption
Security headers, rate limiting, and an append-only audit log
You secure
Strong, unique passwords and two-factor authentication
Workspace membership and prompt removal of departed users
Per-protocol visibility and shared-project settings
What data you choose to upload, especially regulated data
Operational security
Continuous monitoring
Automated database security advisors run against our schema — flagging misconfigured access policies, exposed functions, and missing row-level security — and our dependencies are re-audited weekly against newly disclosed vulnerabilities. Errors and uptime are monitored in production.
Secure development
Every change runs a CI gate — type-checking, thousands of automated tests, linting, and a production build — plus a security pipeline: static analysis (SAST), secret scanning, dependency-vulnerability auditing, and a software bill of materials (SBOM). Cryptographic primitives come from a single FIPS-approved module, and secrets are injected at runtime from an encrypted vault, never committed.
Data minimization
We collect only what is needed to operate the Service. Analytics consent is denied by default until you opt in.
Incident response
Security events are logged to an append-only audit trail, and we maintain a written incident-response plan (detect, contain, recover, notify). Suspected vulnerabilities can be reported to security@oltodiscovery.com for coordinated disclosure.
Backups & recovery
Encrypted backups managed by our database provider. Specific recovery and retention behavior depends on the provider plan in effect.
Third-party rigor
We rely on SOC 2-compliant infrastructure providers where available and require all data processors to maintain appropriate safeguards.
Controls in your account
Manage your account security from Settings.
Two-factor authentication (TOTP) with single-use recovery codes
Password change with last-changed timestamp
Login history with device and IP review
Sign out of every device and session at once
Granular profile visibility controls
Configurable session timeouts
Per-protocol public/private visibility
Per-account audit-log review
Report a vulnerability
We welcome responsible disclosure. If you believe you have found a security vulnerability, please contact our security team. We will acknowledge your report and work with you on a coordinated fix.