Skip to main content

​
Multi-tenant isolation

sureops is a multi-tenant platform. Every data access is governed by row-level security (RLS) enforced at the database layer.

​
How isolation works

Each row in every table carries an organization_id. PostgreSQL RLS policies enforce that your session can only read and write rows belonging to your organization. This check happens at the database level — not in application code — so it cannot be bypassed by a bug in the API layer. The RLS model uses three helper functions:
  • user_org_id() — extracts your org from the session JWT
  • user_role() — extracts your role from the JWT
  • has_min_role(min_role) — checks whether your role meets a minimum level
Every API request is evaluated against these constraints. A query that tries to access another organization’s data returns zero rows — not an error that might leak information about whether the data exists.

​
Immediate revocation

Role changes take effect on the very next request. There is no JWT-scope expiry delay. If you remove a user or downgrade their role, their access changes before their next click. See Roles & Permissions for details.

​
Data flow

​
What sureops reads during an incident

When an incident is active, sureops reads:
  • Alert data ingested from your monitoring integrations
  • Metrics, logs, and traces via MCP tool calls during agent execution
  • Your runbooks and service catalog from your .sureops/ contract (for diagnosis grounding)
sureops reads the minimum data necessary to diagnose and resolve the incident. Tool queries are targeted — they ask for specific metrics in a specific time window, not bulk exports of your telemetry.

​
What sureops writes

sureops writes to its own database:
  • Incident records, stage records, and timeline entries
  • AI analysis results, recommendations, and approval decisions
  • Audit log entries
sureops does not write back to your observability platform, source code, or infrastructure — except:
  • Fix-PR agent: opens a draft pull request in your GitHub repository (requires explicit enablement and a HITL approval gate)
  • Incident communications: posts to your Slack channels (requires explicit enablement and a HITL approval gate per message)

​
Telemetry data lifecycle

Metric, log, and trace data queried during an incident is used to construct agent context. The raw query results are not stored as permanent records. What persists:
  • The agent’s synthesized analysis (natural language summary with citations)
  • The specific tool call inputs and outputs as part of the incident timeline
Raw telemetry is not retained beyond what the agent needs for the active incident.

​
LLM data handling

​
Context construction

When sureops calls an LLM — for diagnosis, resolution planning, chat, or post-incident analysis — it constructs a prompt from:
  • Incident metadata (service name, severity, timestamps)
  • Tool call results (metrics, log excerpts, traces)
  • Your runbook content (from .sureops/runbooks/)
  • Prior stage summaries from the same incident

​
PII redaction

Before any context is sent to an LLM, sureops applies a PII/secrets redaction layer. This layer detects and redacts:
  • Personal identifiable information (names, email addresses, IP addresses)
  • Secrets and credentials (API keys, tokens, passwords)
  • Other common sensitive patterns
Redacted values are replaced with labeled placeholders so the agent can reason about the structure of the data without seeing the sensitive content.
PII redaction applies in both managed-LLM mode and BYOK mode. It is not optional and cannot be disabled.

​
BYOK vs. managed LLM

  • Managed: sureops provides the LLM API keys and operates the provider accounts. Data flows from sureops to sureops-operated provider workspaces.
  • BYOK (Bring Your Own Key): You provide your own API keys. Data flows from sureops to your provider account directly. Your provider’s data retention and processing terms govern the LLM side.
For full details on the data flow differences between managed and BYOK, see BYOK vs Managed LLM.

​
Self-hosting

Self-hosted deployments give you full data sovereignty. sureops runs entirely within your infrastructure — no data leaves your environment. Self-hosting is available on Enterprise plans. In self-hosted mode:
  • The backend and database run in your Kubernetes cluster
  • LLM calls go to your own provider endpoints (BYOK only in self-hosted)
  • No telemetry or incident data is sent to sureops infrastructure
  • You control upgrades, backups, and retention policies
Contact hello@sureops.ai for self-hosting availability.

​
Compliance posture

​
SOC 2

sureops is pursuing SOC 2 Type II certification. The controls described on this page — RLS-enforced isolation, append-only audit logs, immediate revocation, PII redaction — are part of the controls framework. Contact sureops support for the current status and to request our security questionnaire responses.

​
GDPR

sureops supports GDPR compliance for customers in the EU:
  • Data residency: EU-region deployments are available on request
  • Data processing agreement (DPA): available for customers who require one
  • Right to erasure: incident data deletion is available on request for specific incidents

​
Encryption

  • Data at rest: encrypted using AES-256
  • Data in transit: TLS 1.2 minimum on all connections
  • LLM API keys: stored encrypted with a per-org derived key; the raw key is never exposed via the API

​
Reporting a security issue

Report security vulnerabilities to security@sureops.ai. We aim to acknowledge within 24 hours and provide a status update within 72 hours.