Security architecture, stated plainly
A security product should be specific about itself. This page lists the controls that exist, the responsibilities that stay with you, and what we do not claim.
Controls in the product
Based on the product code and its automated tests. Not an independent audit.
JWT authentication with bcrypt password hashing and refresh tokens
Token-based login, bcrypt password hashes, refresh tokens.
Role-based access control
Roles for super admin, admin, SOC manager, analyst, viewer and a platform developer role for platform-level controls.
Tenant-scoped data and policy
Data models and APIs carry a tenant identifier; LLM policy and provider assignment are set per tenant.
Note: Isolation has not been independently audited. Never claim complete isolation.
Hash-chained audit trail for AI and response activity
AI model calls and live response attempts are written to a hash-chained audit log.
Masking of secrets and personal data before external LLM calls
Prompts are masked before they leave for an external provider. By default credentials and secrets are masked; wider personal-data masking is a configuration option (LLM_PII_MASK).
Note: Masking reduces exposure; it is not a guarantee. Local models keep data on the operator's infrastructure.
LLM usage log, token budgets and per-tenant LLM policy
Every model call is logged with provider, tokens and outcome; a daily token budget degrades analysis to a lighter mode; policy can restrict a tenant to rules only, open-source models or paid providers.
Data flow and AI configuration
ThirdEYE is deployed in your environment. Events from your sources are stored in the database you choose.
If you enable a cloud LLM, alert context is sent to that provider after masking. By default credentials and secrets are masked, and wider personal-data masking is a setting. You can instead use local Ollama models, so prompts stay on your infrastructure, or run with built-in rules only. Policy is set per tenant.
Every model call is logged with provider, tokens and outcome. Live response attempts are written to a hash-chained audit log.
Your responsibilities
- Set strong secrets. Development defaults in the sample compose file, such as SECRET_KEY, must be replaced.
- Put the platform behind TLS and restrict network access to it.
- Store provider and connector credentials in your own secret management.
- Decide data retention and backup for your database.
- Choose which AI providers may see alert data.
- Enable live response only after testing a provider in simulate mode.
What we do not claim
MFA and enterprise SSO for operator login
Not found for operator login. One-time codes exist for self sign-up only.
Compliance certifications and independent audits
None found. Do not claim SOC 2, ISO 27001, GDPR or similar.
Benchmarks, uptime figures and scale numbers
None published. Local load-test artifacts exist but are not customer evidence.
No SOC 2, ISO 27001, GDPR or similar attestation, no guaranteed data residency, and no claim of complete tenant isolation. Isolation has not been independently audited.
Need specifics for your review?
Tell us what your security team needs to see. We will answer from the product and its code, and say where we cannot.