Security is not an add-on for us. It is part of how SEER is built. Here is exactly what we do to protect your data and your AI infrastructure — no jargon, no vague reassurances.
All data is encrypted in transit with TLS 1.3 and at rest with AES-256. This applies to every call record, every quality score, and every dashboard session.
Your data is stored in a separate namespace from every other customer. No shared tables. No cross-account queries. No way for one account's data to touch another's.
Every call record is written once and cannot be altered. Your audit trail is genuinely immutable — useful for compliance and for debugging problems after the fact.
Every connection to SEER — from your application, from the dashboard, and from our internal services — uses TLS 1.3. Older versions of TLS are rejected. We use HSTS to prevent protocol downgrade attacks, and our certificates are managed and rotated automatically.
If you use webhooks, SEER signs every payload with HMAC-SHA256 so you can verify the request is genuinely from us before acting on it. Instructions for verifying signatures are in the API docs.
All stored data — call records, quality scores, account details, and any content you opt into storing — is encrypted using AES-256. Encryption keys are managed separately from the data they protect, rotated regularly, and stored in a dedicated key management service.
By default, SEER does not store your raw prompt text or model completion text. It records metadata: latency numbers, token counts, cost, quality scores, and anomaly signals. If you opt into full content recording (available on Growth and Scale plans), that content is encrypted with a key unique to your account.
You access your SEER account with email and password, or via Google or GitHub SSO. We recommend enabling SSO if your team already uses it. Scale plan customers can enforce SSO for all team members and set minimum password requirements via their settings.
Two-factor authentication is available on all plans and strongly recommended. We will prompt you to enable it if it has not been set up.
API keys are scoped and controllable. You can restrict a key to specific contexts so a key used in one part of your application cannot read or write data from another part. You can see the last time any key was used and revoke keys instantly from your dashboard. We recommend creating separate keys for production, staging, and development environments.
You can invite team members to your SEER account and assign them roles. Admins can manage billing, keys, and team members. Developers can access call data and recommendations. Read-only members can view reports but cannot make changes. Each role sees only what they need.
SEER runs on AWS infrastructure across multiple regions. We use separate infrastructure for ingesting call data versus serving the API and dashboard — so a spike in one does not affect the other. Both are behind load balancers with automatic failover.
Call data is written to a time-series database optimised for write-heavy workloads. Reads (queries, dashboards, recommendations) go to a read replica, not the primary. This means your monitoring never slows down your own data recording.
Our internal services communicate over private VPC networking. No internal traffic touches the public internet. Access to production infrastructure requires VPN, is role-based, and is logged. We review access logs weekly.
We do not sell your data to third parties. Full stop. We use a small number of trusted sub-processors to run the service:
Each sub-processor has been assessed for security practices and is bound by data processing agreements. None of them have access to your call content or raw AI data — only the minimum they need to do their specific job.
If your organisation requires a signed DPA, email us at and we will arrange it promptly. We do not charge for DPAs.
We take incidents seriously. Our incident response process works like this:
Detection. Our monitoring systems run continuously and alert our team automatically if anything unusual happens. We aim to detect incidents within minutes.
Response. We have an on-call engineer available at all times. Once an incident is confirmed, we open an internal incident channel and start working on it immediately.
Communication. We update status.seerlabs.api throughout any incident so you can see what is happening in real time. We do not go quiet and hope nobody notices.
Data breaches. If a breach occurs that involves your personal data, we will notify you within 72 hours — in line with GDPR requirements — with details of what happened, what data was involved, and what we have done about it.
Post-incident review. After every significant incident we write a plain English post-mortem and publish it. We share what went wrong, what we did, and what we have changed to stop it happening again.
Found a security vulnerability in SEER? Please tell us before you tell anyone else. Email with the details. We will acknowledge your report within 24 hours, investigate thoroughly, and keep you updated throughout. We do not take legal action against researchers who disclose vulnerabilities responsibly. If your report leads to a fix, we will thank you publicly (unless you prefer to stay anonymous).
Please do not test for vulnerabilities against production customer data or attempt to access data that is not yours. Use our sandbox environment for any testing — contact us and we will set one up for you.
Have a security question that is not answered here? Reach our secu