Security Whitepaper

Pulsent Labs Inc.
Last updated: 2026-05-20
Document owner: Arseniy Shishaev, CTO
Contact: security@superlog.sh

1. About Superlog

Superlog is an OpenTelemetry-compatible observability backend operated by Pulsent Labs Inc. Customers send OTLP logs, traces, and metrics to our ingest endpoint; we group errors into issues, group issues into incidents, and run an investigation agent that posts updates to Slack and (where confidence is high) opens a fix PR on the customer's repository through our GitHub App.

This document describes how Superlog protects customer data, the boundary controls in place today, and the items on our compliance roadmap.

2. Architecture overview

2a. Architecture diagram

2b. Architecture description

─── Telemetry ingest ───────────────────────────────────────────────────────
  customer app ──OTLP/HTTPS──▶ intake.superlog.sh (Auth Proxy)
                                     │ hashes API key, stamps project_id
                                     ▼
                                OTel Collector ──▶ ClickHouse
                                     │ strips client-supplied superlog.* attrs

─── Application ────────────────────────────────────────────────────────────
  customer browser ──HTTPS──▶ superlog.sh / api.superlog.sh
                                     │ Better Auth session, project-scoped reads
                                     ▼
                                 Postgres

─── Investigation (per incident) ───────────────────────────────────────────
                       ┌── Worker (Pulsent code) ───────────────────────┐
                       │  Holds the customer-facing credentials:         │
                       │    • GitHub App installation token              │
                       │    • Slack bot token                            │
                       │    • Linear OAuth (via Anthropic Vault)         │
                       │    • ClickHouse read access                     │
                       └────────────────────┬────────────────────────────┘
                                            │
                       ─────── credential boundary ───────
                                            │
                            (1) mount candidate repos as filesystem
                            (2) issue read-only telemetry MCP (3h TTL)
                                            ▼
                       ┌── Anthropic Managed Agents ────────────────────┐
                       │  Per-incident sandboxed session                 │
                       │  Holds NO github / slack / clickhouse tokens    │
                       │  Iterates: read files, run tests, edit in place │
                       └────────────────────┬────────────────────────────┘
                                            │
                            (3) returns patch bundle + validation result
                                            ▼
                       ┌── Worker (Pulsent code) ───────────────────────┐
                       │  (4) re-applies patch in a fresh clone          │
                       │  (5) re-runs validation; confidence gate        │
                       │  (6) on pass: opens PR, posts Slack,            │
                       │      creates Linear ticket                      │
                       └────────────────────┬────────────────────────────┘
                                            │
                                            ▼
                         customer's GitHub / Slack / Linear

The credential boundary is the central security property of the investigation flow: every customer-facing write (GitHub PR, Slack post, Linear ticket) is performed by Pulsent-controlled worker code, never by the LLM-driven agent. See §7 for the full description.

Production domains

All public endpoints are HTTPS-only and fronted by Cloudflare.

Hosting and data residency

All production compute and storage runs on Railway (United States West Coast region). This includes:

• web, api, worker, proxy Node.js services
• Managed PostgreSQL (application metadata, accounts, configuration)
• Managed ClickHouse (customer telemetry — logs, traces, metrics)
• OpenTelemetry Collector (otelcol-contrib)

ClickHouse has no public endpoint — it is reachable only over Railway's internal network. Inter-service traffic inside Railway is encrypted.

DNS and edge proxying are provided by Cloudflare. WAF and rate-limiting controls are configured at the Cloudflare layer.

Customer data residency

Customer telemetry and metadata are stored in the United States (Railway). EU-specific data residency is on the roadmap (see §15).

3. Authentication and identity

End-user authentication

User authentication is handled by Better Auth. Sessions are database-backed (Postgres sessions table), not bearer JWTs, so revocation is immediate.

Supported credentials:

• Email + password — passwords hashed by Better Auth (scrypt with per-user salt). Reset flow uses one-time email links with 1-hour expiry.
• Google OAuth (enabled when configured).
• GitHub OAuth (enabled when configured).

Sessions use Secure, HttpOnly, SameSite=Lax cookies scoped to .superlog.sh so that superlog.sh and api.superlog.sh share a session domain. Cross-site requests carry the session cookie only over HTTPS.

Email verification is sent on sign-up. Gating application access on a verified address is on the roadmap.

Roadmap

• Multi-factor authentication (MFA) — TOTP and WebAuthn — targeted for H2 2026, before SOC 2 Type II.
• SAML SSO / OIDC SSO — targeted for 2027, driven by enterprise demand.
• SCIM provisioning — targeted for 2027, alongside SSO.

Machine-to-machine credentials

We never store any ingest, management, or session credential in plaintext. Loss of a key cannot be recovered — the customer mints a new one and revokes the old.

4. Multi-tenant isolation

Superlog is a multi-tenant SaaS. Tenant isolation is enforced at multiple layers:

Ingest path (intake.superlog.sh)

1. The auth proxy extracts the API key from x-api-key or Authorization: Bearer.
2. The plaintext key is SHA-256 hashed and looked up against api_keys.key_hash in Postgres.
3. The proxy stamps the request with x-superlog-project-id corresponding to the validated key and forwards to the collector.
4. The OTel collector strips any client-supplied superlog.* attributes from every span, log, metric, and resource scope — defense-in-depth against tenant spoofing.
5. The collector then writes the proxy-stamped superlog.project_id as a resource attribute on every row inserted into ClickHouse.

Read path

The API gates every customer-facing read on:

• a valid Better Auth session,
• membership in the requesting org (via org_members),
• access to the requested project (via projects.org_id).

ClickHouse reads always filter on ResourceAttributes['superlog.project_id'] from the project the session is scoped to. There is no SQL string interpolation of project IDs — they are parameterized at the query layer.

Org boundary

The data model is rooted at orgs. Every customer-owned record (projects, api_keys, incidents, issues, investigations, dashboards, alerts, integrations) descends from a single org_id with ON DELETE CASCADE. Org-level deletion is a single transactional operation.

5. Encryption

In transit

• All public endpoints require TLS 1.2 or higher with modern cipher suites (Cloudflare-managed).
• Internal traffic between services runs over Railway's internal network with TLS where exposed; database connections from app services to managed Postgres / ClickHouse use Railway's encrypted private networking.
• OTLP ingest is HTTPS-only on intake.superlog.sh. Plain HTTP is not accepted in production.

At rest

• Postgres: AES-256 encryption at rest provided by Railway's managed Postgres.
• ClickHouse: AES-256 encryption at rest provided by Railway's managed ClickHouse.
• Application-level encryption for third-party integration secrets: secrets stored in org_integration_secrets are encrypted with AES-256-GCM using a 256-bit master key (AGENT_SECRETS_KEY), with per-record 96-bit random nonces and AEAD authentication tags. The schema supports key versioning for rotation.
• OAuth provider tokens (Slack bot tokens, Linear access tokens) granted to Superlog by customers' workspaces are currently stored unencrypted in Postgres. Migrating these to the AES-256-GCM envelope is on the security roadmap.

Key management

• Master encryption keys (BETTER_AUTH_SECRET, STATE_SIGNING_SECRET, AGENT_SECRETS_KEY, etc.) are stored as Railway environment variables and are never checked into source control.
• Key rotation: integration-secret keys support per-record versioning so rotation can be performed incrementally without downtime.

6. Customer data handled

Stored in Postgres (application metadata)

• User identity: email, name, profile image URL, hashed password (when email/password is used).
• Org/project configuration: names, slugs, integration settings.
• Hashed credentials only (ingest keys, CLI tokens, OAuth grants — see §3).
• Issue fingerprints, incident records, investigation results, and PR/ticket references.
• OAuth installation records for GitHub, Slack, Linear (account/team identifiers, installation IDs, and tokens — see §5).

Stored in ClickHouse (customer telemetry)

• OTLP logs, traces, and metrics as sent by the customer's instrumented applications.
• Customers control what attributes and bodies they send. Superlog does not inspect or transform telemetry content beyond OTel-standard processing.

Sent to subprocessors

See subprocessors for the complete table. In short:

• Anthropic receives investigation prompts that may include log lines, stack frames, and source code from the customer's repo (read via the GitHub App) — this is the agent's working context.
• Resend / Loops receive end-user email addresses and names for transactional and lifecycle messages.
• PostHog (EU) receives product-analytics events from the web app.
• Slack / GitHub / Linear receive only the data the customer has connected them to.

Sensitive data Superlog does not collect

• We do not collect, transmit, or store payment card data on Superlog systems. Billing is handled by Stripe (PCI-DSS Level 1 service provider) via Stripe-hosted checkout and invoicing. Customers enter card details directly into Stripe's environment; Superlog stores only Stripe-issued tokens (customer ID, subscription ID) and the billing contact (name, email, optional company name). Superlog's environment is therefore outside PCI cardholder data scope.
• We do not collect health information, government identifiers, or biometric data.

7. Investigation agent — credential boundary

A core security commitment of Superlog is that the investigation agent never holds the credentials it would need to take action on a customer's behalf. Customer-affecting writes — opening pull requests, posting to Slack, querying customer telemetry — are mediated by Superlog code (the "worker") that we operate, audit, and update. The agent runs in an isolated Anthropic Managed Agents session, reasons over evidence we mount into the session, and returns a structured proposal. The worker validates that proposal and is the only component that calls third-party APIs.

Why this matters

The investigation agent is the highest-risk component in the system: it is an LLM, it reasons over untrusted customer data (logs, stack traces), and it produces code. If the agent were given a long-lived GitHub write token, a Slack bot token, or a Linear API key, a successful prompt injection or model manipulation could result in unauthorized PRs, Slack posts, or ticket spam. We have intentionally architected the system so that the credentials for those actions never enter the agent's context.

Hard split — customer-affecting writes are worker-only

The agent has no path to call the GitHub API, the Slack API, or ClickHouse directly.

How a fix actually reaches the customer's repository

1. The worker enumerates the customer's GitHub App-installed repositories, scores them against the incident's service name and stack frames, and selects the top-3 candidates.
2. The worker provisions the candidate repositories into the agent's Anthropic Managed Agents session as a filesystem mount. The GitHub App installation token is used by Anthropic's backend to populate the sandbox; it is not surfaced to the model, and the model has no shell or tool path that can use it to call the GitHub API.
3. The agent investigates inside its sandbox: reads files, runs the customer's tests, iterates on a hypothesis, edits files on the sandbox filesystem.
4. The agent returns a structured patch bundle (patch, patchFilePath, validationCommands, validationSummary, validationPassed, changedFiles). The agent never opens a PR, never calls git push, and never invokes the GitHub API.
5. The worker takes the agent's patch, applies it to a fresh clone of the target repo using the worker's own GitHub App credentials, re-runs the validation commands, and only then opens the PR through the GitHub App.
6. The PR is opened by a Superlog-identified bot account, clearly labeled as AI-generated, and never auto-merged. A human on the customer's team always performs the merge.

A confidence gate in the worker rejects the patch — no PR is opened — if any of these fail: repo selection was low-confidence, the bug wasn't validated by the agent, the patch doesn't apply cleanly to a fresh clone, or post-fix validation fails.

Slack — worker only

Messages to the customer's Slack workspace are posted exclusively by the worker, using the bot token stored in Postgres (see §5) and loaded into worker memory at run time. The agent holds no Slack credentials and has no network path to the Slack API. Customer replies to investigation threads are received by the worker via Slack's Events API and forwarded to the agent's session as plain text — not as Slack API access.

Linear — softer boundary, mitigated by vault

Linear ticket creation today uses Anthropic Vault: the worker refreshes the customer's Linear OAuth access token, stores it as a credential reference inside an Anthropic Vault attached to the agent's session, and the agent invokes Linear via a tool call. The raw token is not visible to the model's context — the vault returns a credential reference that Anthropic's tool runtime resolves at call time.

This is a softer boundary than the GitHub flow: the agent has the capability to create tickets, just not direct access to the token. We have a roadmap item to move Linear ticket creation behind the same patch-then-worker-acts pattern used for GitHub, eliminating this difference.

What the agent does hold

• A read-only filesystem mount of the candidate repositories. Filesystem-level access only; no GitHub API token.
• A time-bounded MCP access token (3-hour TTL) scoped to read-only telemetry access for the target organization's projects. The token cannot mutate any customer state.
• A vault credential reference for Linear, where the customer has enabled the Linear integration (see above).

No other customer-affecting credentials enter the agent's session.

Sandbox isolation

Each investigation runs in a fresh Anthropic Managed Agents session with per-session filesystem isolation and Anthropic-controlled outbound network policy. Sessions do not share state across investigations or across customers.

Audit trail

Every action the worker takes on a customer's behalf — repo selection, patch application, validation result, PR open, Slack post, Linear ticket create — is recorded in Superlog's own audit log (see §9) and surfaced to the customer in the investigation timeline.

8. Application security

Secure software development

• Languages: TypeScript across all services with strict mode enabled.
• Source control: GitHub, single production branch (main).
• Code review: pull requests required for merges to main. Branch protection is enforced and a CODEOWNERS file routes review of security-sensitive paths to the Security Lead.
• Static analysis: Biome enforces lint/format on PRs.
• Dependency management: pnpm with a locked workspace. Dependency-update automation via Dependabot is on the roadmap.
• Testing: unit and integration tests for security-sensitive flows (auth, signup intents, GitHub App).
• Migrations: schema changes only via Drizzle's generate workflow (no hand-edited SQL).

Input handling

• All HTTP endpoints use Hono's typed routing with schema validation (Zod).
• Database access goes through Drizzle ORM with parameterized queries; no string-concatenated SQL.
• The OTel collector strips any client-supplied superlog.* attribute before persistence (see §4).

Secrets in code

Repository scans for secrets are performed pre-commit by developers' tooling. Repository-side secret scanning (GitHub Secret Scanning + push protection) is enabled at the GitHub organization level.

Customer-supplied URLs

Management-API flows that redirect back to a customer-controlled URL (e.g. GitHub install bounce-back) validate the host against an explicit per-org allowlist (orgs.allowed_return_url_hosts) — the management key alone is not a sufficient gate against open-redirect phishing.

9. Logging, monitoring, and self-instrumentation

Superlog uses Superlog. The web, api, worker, and proxy services emit OTLP traces, logs, and metrics to intake.superlog.sh using a dedicated ingest key scoped to our own production project.

• Application logs — structured JSON via Pino, shipped to ClickHouse.
• Traces — OpenTelemetry SDK with auto-instrumentation for HTTP, database, and outbound calls.
• Audit trail — security-relevant events (sign-in, key creation, key revocation, org membership change, integration install/revoke) are captured as application logs.
• Uptime — Railway service health checks; Cloudflare edge availability monitoring.

10. Vulnerability management

• All third-party dependencies are tracked in pnpm-lock.yaml for reproducible installs.
• Dependency vulnerabilities are remediated under documented SLAs: Critical 7 days, High 30 days, Medium 90 days, Low best-effort. Fixes ship via the normal deploy pipeline.
• Third-party penetration testing: commissioned for Q2 2026, aligned with the SOC 2 Type I attestation. Current state: internal security review only.

11. Incident response

We maintain an Incident Response Plan covering detection, triage, containment, eradication, recovery, and post-incident review.

Customer notification SLA for confirmed security incidents involving customer data: within 72 hours of confirmation, via the email address of record for the org owner, and via in-app notification.

12. Business continuity and disaster recovery

• Postgres: Railway managed daily backups, retained per Railway's policy. Point-in-time recovery available within the retention window.
• ClickHouse: Railway-managed daily snapshots with 7-day retention (Railway default). Restore drill scheduled for Q2 2026.
• Service redundancy: Railway provides instance restart on failure. Multi-region active-active is not in scope for current architecture.
• RPO: ≤ 24 hours (database backup cadence).
• RTO: target ≤ 4 hours for application availability following infrastructure failure. Tabletop drill scheduled for Q2 2026.

13. Access control (employee)

• All employee access to production systems is gated on:
  • Single sign-on through Google Workspace with MFA required.
  • Least-privilege role assignment.
  • Quarterly access review.
• Production database (Postgres, ClickHouse) credentials are stored in Railway and rotated when an employee with access leaves. There is no shared "root" credential in regular use.
• Engineering laptops are full-disk encrypted with FileVault (enforced) and managed via Jamf MDM.

14. Subprocessors

The current subprocessor list is maintained at subprocessors. We commit to providing 30 days' advance notice to customers under an active DPA before adding a new subprocessor that processes customer data.

15. Compliance roadmap

• SOC 2 Type I: target Q2 2026. Compliance automation: Probo (engaged Q2 2026). Auditor: to be selected via Probo's auditor network.
• SOC 2 Type II: target Q4 2026 (immediate 6-month observation window following Type I).
• GDPR: DPA available on request. Customer data is processed in the United States today; EU-region option is on the roadmap.
• HIPAA: not in scope — Superlog is not authorized to process PHI. Customers must not send PHI in telemetry.
• ISO 27001: not currently pursued.

See soc2-roadmap for the full plan.

16. Contact

• Security disclosures: security@superlog.sh
• Sales / security questionnaires: legal@superlog.sh
• Status page: planned for Q2 2026