Security & Compliance

​

Multi-tenant isolation

sureops is a multi-tenant platform. Every tenant-scoped table carries an organization_id — either directly, or inherited through a parent table’s foreign key for child tables that belong to a parent record.

​

How isolation works

The primary enforcement point is application code, not the database. The backend’s API layer authenticates to the database with elevated, RLS-bypassing credentials, so on that path — the one every API request takes — Postgres row-level security is not what’s keeping your organization’s data separate from another organization’s. Instead, every query the backend issues is scoped to your organization explicitly: either as a filter on the query itself, or as an ownership check performed before the request is allowed to read or write the record at all. PostgreSQL RLS policies do exist on these tables, using 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

These policies are a secondary layer: they apply to a database session that connects directly with your own credentials rather than going through the backend API. They are not a substitute for the application-level org-scoping above, and a bug in that application-level check is not caught by RLS on the API path — there’s no second database-level check backstopping it there. A request that tries to access another organization’s data is rejected before the query runs, or is scoped to return nothing for that organization — either way, you get a not-found rather than another org’s records.

​

Revocation timing

Role and access changes take effect on the affected user’s next token refresh or next sign-in — not on their very next request. Role is a claim baked into the session JWT at issuance, so a request made with an already-issued token still carries the old role until that token is refreshed or reissued. For an offboarding runbook, plan for that window: a token issued before the role or membership change keeps working at its old privilege level until it expires or is refreshed — it is not invalidated retroactively. 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 — these status updates are not individually gated behind a HITL approval; the fix-PR gate above is separate and unaffected)

​

Telemetry data lifecycle

Metric, log, and trace data queried during an incident is used to construct agent context. What persists in sureops’s database:

• The agent’s synthesized analysis (natural language summary with citations)
• The specific tool call inputs and outputs — the raw query results — as part of the incident timeline and the agent’s checkpointed state

This data is retained as part of the incident record; it is not deleted automatically when the incident closes. Deletion happens only through an explicit action — see “Right to erasure” below, or contact sureops support.

---

​

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

sureops applies a PII/secrets redaction layer before any context is sent to the LLM whenever an org’s LLM mode is managed or demo/trial — internally, demo/trial is treated as a case of managed mode for this purpose, so it gets the identical redaction path, not a lighter one. Since sureops-managed mode itself isn’t launched yet (see below), in practice this means the redaction layer is live today for demo/trial environments. This layer detects and redacts:

• Personal identifiable information (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 with less exposure to the underlying sensitive content. This is a mitigation, not a guarantee — pattern-based detection can miss novel or unusually-shaped secrets, so redaction reduces exposure rather than eliminating it outright.

​

BYOK vs. managed LLM

Two LLM key modes are live today:

• 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. This is the default, and the only mode available for a production organization today.
• Demo/trial: sureops supplies LLM capacity so you can evaluate the product without bringing your own provider key. That traffic runs through inference-hosting providers serving open-weight models, under data-processing terms that restrict retention and prohibit training on your content — not through a sureops-operated Anthropic or OpenAI account.

A third mode — sureops-managed Anthropic/OpenAI — has been designed but is not launched: the required enterprise agreements aren’t signed and it isn’t available for signup. See BYOK vs Managed LLM for the full picture, including what managed mode would mean once it ships.

---

​

Self-hosting

Self-hosted deployments give you full data sovereignty over your infrastructure and telemetry. sureops runs entirely within your infrastructure — no data leaves your environment to sureops servers. LLM calls are the one exception: they still go to your chosen provider (BYOK only in self-hosted), since that’s an external inference call by nature, not something self-hosting eliminates — your provider’s data-processing terms govern that leg, same as in SaaS BYOK mode. 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) — the only traffic that leaves your environment, and it goes to your provider, never to sureops
• No telemetry or incident data is sent to sureops infrastructure
• You control upgrades, backups, and retention policies

See the Helm chart deploy guide for the deployment mechanics. Contact hello@sureops.ai for current availability and plan eligibility.

---

​

Compliance posture

​

SOC 2

sureops is pursuing SOC 2 Type II certification. The controls described on this page — application-layer org-scoping on every query (with RLS as a secondary layer on direct database sessions), append-only audit logs, role revocation, managed/demo-trial 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 processing agreement (DPA): available for customers who require one
• Right to erasure: incident data deletion is available on request for specific incidents

Contact sureops support to discuss data residency requirements for your organization.

​

Encryption

• Data at rest: encrypted using AES-256
• Data in transit: encrypted via TLS
• 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.