Trust & Legal

Trust by architecture, not by promise.

Promises are easy. Architecture is permanent. Sarthy enforces trust the same way it enforces alignment, in the code, not the contract.

1. Self-hosted

Sarthy installs on your own infrastructure. Single container, Postgres, Redis. Your knowledge base, audit log, and all content live on your server. We have no production access to your install.

2. DMs sealed (Pr03)

Direct messages between people are never alignment-processed. Enforced at five separate layers:

  • Database layer. DM table has no alignment column. The schema cannot represent it.
  • API layer. No endpoint exposes DM content to the agent. Returns 404.
  • Agent code. Explicit rejection on target_kind = dm_message, with audit emission.
  • Search index. DM content excluded at index-build time, CI test enforces.
  • MCP surface. MCP tools cannot return DM content. Defense-in-depth.

3. Append-only audit

History cannot be rewritten. The audit log is append-only at the schema level (no UPDATE permission to the table, even for admins). Every state-changing action emits an audit event. Backed by SQLite WAL with daily backups to MinIO.

4. Role-filtered access

Least-privilege by default. The RBAC matrix is enforced server-side, not just in the UI. Every query is scoped by the requester's role and project access. Wiki pages, search results, and Ask Sarthy responses all respect the user's accessible paths.

5. Merge-locked builds (V1.25)

Half-built code cannot land on main. The Open-Card Merge Lock ensures every related card closes before a feature merges. Architectural, not policy. A determined developer cannot bypass it under pressure.

6. LLM-agnostic by design

Provider-agnostic abstraction. V1 ships Claude and OpenAI adapters. Your LLM calls go directly from your server to your chosen provider. No Sarthy intermediary, no Sarthy logging of LLM content, no Sarthy access to your provider keys (they live encrypted on your server with install-kek).

Operational security.

Encryption

  • TLS 1.3 in transit (or TLS 1.2 minimum if your environment requires)
  • AES-256-GCM at rest for sensitive fields (LLM provider keys, MCP PATs, encrypted config)
  • Database encryption is your responsibility (and your choice of cloud or on-prem)

Authentication and authorisation

  • Sarthy-native authentication (login, password reset, signup invitations) per D074
  • Per-user MCP Personal Access Tokens, SHA-256 hashed, AES-256-GCM encrypted with install-kek
  • Tokens are one-time-reveal at creation; we cannot recover lost tokens, you regenerate
  • Constant-time comparison on token verification; reverse-proxy header redaction

Backups and recovery

  • Daily backup at 02:00 UTC of SQLite, knowledge repo, encrypted config to MinIO
  • Retention cron at 03:00 UTC enforces your retention policy
  • Owner-triggered restore with five-second confirmation and full audit trail

Vulnerability disclosure

Found a security issue? Email security@sarthy.io with a description and any reproduction steps. We acknowledge within 24 hours, triage within 72 hours, and coordinate disclosure with you. No bounty programme yet; we're a small company. We'll credit you publicly if you'd like.

Do not report security issues through GitHub issues or the demo form. Use the email above.

Compliance

Sarthy is built to support SOC 2, ISO 27001, and GDPR audit requirements through Module 22 (Compliance Evidence Export). Sarthy itself is not currently SOC 2 or ISO 27001 certified; certifications are on the roadmap as we scale. The architecture is designed to satisfy auditors when your install is in scope of those certifications.

Bring your security team

Walk through the architecture with us.

Twenty minutes. We install Sarthy on your server and open every architectural choice, layer by layer. Bring questions, bring auditors, bring the InfoSec team.

Book a demo