Trust center

All traffic is served over TLS.

Data-source credentials are encrypted with AES-256-GCM using envelope encryption with per-record data keys.

Master keys are held by the configured key provider and are rotatable without re-encrypting stored credentials.

reportable.sh only ever issues SELECT statements against connected sources.

Enforced by three independent layers: a per-dialect SQL guard, a READ ONLY transaction, and the customer's own role grants. Whether the supplied role is genuinely read-only is probed at connect time and re-checked periodically.

Every query is scoped to a workspace, resolved server-side from the session.

Workspace identity is never accepted from client input.

Sources can be restricted to named users, teams, or roles, with table denylists, column masking, and row-level policies.

Per-person policies are resolved for every query made on a person's behalf. The platform's own scheduled monitors — anomaly detection and source freshness — run with no person to resolve, so they are bounded by the connection's table scope rather than by per-person rules, and their results are alerts rather than rows.

Source connects, credential changes, role changes, every query the agent runs, exports, and deletions are recorded in an append-only log.

Exportable as NDJSON for SIEM ingestion.

Configurable retention per data class, executed as real deletion.

Workspace data can be exported on request and erased, subject to a grace period.

Data is structurally separated from instructions in tool results, and outbound content is scanned for exfiltration patterns before it reaches a share or an email.

A per-workspace kill switch stops all agent activity immediately.

Sign-up, sign-in, agent runs, source connects, and per-source query volume are rate limited, with a circuit breaker protecting connected databases.

The default limiter store is per-instance; a shared store is a drop-in implementation for multi-instance deployments.

The sub-processor list is published and versioned in source control.

A hosted KMS can be used for master key custody.

Key management is behind a provider interface. The default driver derives master keys from deployment configuration; a hosted KMS is a drop-in implementation but is not configured in this deployment.

OIDC single sign-on with enforced SSO per verified domain, group-to-team mapping, and workspace session policy.

OIDC is implemented end to end: discovery, JWKS, and id-token verification checking algorithm, issuer, audience, expiry and nonce. SAML 2.0 is not implemented — assertion verification there is an XML canonicalization problem that belongs in a vetted library rather than in application code, and the settings page says so rather than failing at a first login.

SCIM 2.0 user and group provisioning, mapping IdP groups to teams.

Users, groups, and deactivation are implemented against the SCIM 2.0 schema. Not yet certified against a specific IdP.

Region preference can be recorded per workspace.

The preference is recorded and shown, but this deployment does not yet pin processing to a region. It is stated as a request, not a guarantee.

An independent SOC 2 Type II audit.

Not yet undertaken. The technical controls a SOC 2 examines are listed above with their real status.

Third-party penetration testing.

No external penetration test has been commissioned. The security-relevant logic — the SQL guard, access policies, row-filter compilation, credential encryption, and the outbound content scanner — carries an adversarial test suite, which is not a substitute for one.