TrustSignal

Status: active

Evidence integrity infrastructure for compliance and audit workflows.

TrustSignal issues signed verification receipts so organizations can prove when evidence was created, where it came from, and whether it has changed. It adds an integrity layer to existing workflows without replacing the system of record.

→ trustsignal.dev · Documentation · Request a Pilot

Developer Access

The public website is the discovery layer. Account creation, sign-in, and API access management should live in the central TrustSignal app so every TrustSignal service validates against one source of truth.

• Public site entry points:
  • /sign-up
  • /sign-in
  • /get-your-api-key
• Central app destination:
  • NEXT_PUBLIC_TRUSTSIGNAL_APP_URL should be set only when the TrustSignal app is actually deployed

This keeps API key issuance out of the marketing/docs repo while still giving developers a clear path into the authenticated product surface. The preferred machine flow is registered public keys plus short-lived access tokens; legacy API keys remain only as a migration fallback.

Supabase

The repo now includes a Supabase CLI scaffold and a TrustSignal-specific security runbook for table classification, RLS defaults, and client exposure.

• Runbook: docs/supabase-security-runbook.md
• Starter schema: supabase/schemas/001_trustsignal_base.sql
• CLI config: supabase/config.toml

The starter schema treats:

• profiles as client-scoped
• api_keys as client-scoped but backend-managed
• verification_log as backend-only

Do not expose new tables to clients until the ownership model is explicit in the schema.

Monetization Setup (Supabase + Stripe)

This app now includes account-scoped auth, API key lifecycle management, and Stripe billing.

Required environment variables:

• NEXT_PUBLIC_APP_URL
• NEXT_PUBLIC_SUPABASE_URL
• NEXT_PUBLIC_SUPABASE_ANON_KEY
• SUPABASE_SERVICE_ROLE_KEY (webhook handler only)
• API_KEY_PEPPER (recommended)
• STRIPE_SECRET_KEY
• STRIPE_WEBHOOK_SECRET
• STRIPE_PRICE_ID

Local setup steps:

1. Configure Supabase OAuth providers (Google + GitHub) and add callback URL:

• http://localhost:3000/auth/callback

2. Apply SQL migrations from supabase/migrations/.
3. Configure Stripe checkout price and set STRIPE_PRICE_ID.
4. Run Stripe webhook forwarding locally to /api/billing/webhook.

Security model for Supabase clients:

• User-facing server components and route handlers use Supabase anon key + session context, with RLS enforcement.
• Service role key is restricted to webhook-only handlers and is not used in user-scoped request paths.

---

The Problem

Compliance and audit teams rely on artifacts that pass through multiple systems. Without a durable integrity reference, provenance becomes difficult to validate during later review:

• Evidence files, exports, and screenshots can change after initial collection
• Weeks or months later, reviewers cannot easily prove where an artifact came from or when it was captured
• Audit readiness weakens without a reliable tamper-evident reference

---

How TrustSignal Works

Submit an artifact or artifact reference -> receive a signed verification receipt -> store it with the artifact -> verify again later when trust conditions matter.

┌─────────────────┐    POST /api/attest-evidence    ┌──────────────────┐
│  Your Workflow  │ ──────────────────────────────► │   TrustSignal    │
│    (Drata or    │                                 │  Integrity Layer │
│  internal GRC)  │ ◄────────────────────────────── │                  │
└─────────────────┘    Signed receipt + signal      └──────────────────┘
        │
        ▼
  Store receipt alongside artifact in your system of record
        │
        ▼
  Later verification: compare current artifact against original receipt

Verification Request

POST /api/v1/verify
Content-Type: application/json

{
  "source": "encompass",
  "loan_number": "2026-03-0042",
  "document_type": "borrower_w2_2025",
  "event_type": "income_document_received",
  "artifact_hash": "sha256:93f6f35a550cbe1c3f0b5f0c12b9f0d62f3f9c6f8c6a4eddd8fa1fbfd4654af1",
  "timestamp": "2026-03-11T21:00:00Z",
  "policy_profile": "mortgage_loan_file_integrity_v1"
}

Signed Receipt Response

HTTP/1.1 201 Created

{
  "receipt_id": "tsig_rcpt_01JTQY8N1Q0M4F4F5T4J4B8Y9R",
  "status": "signed",
  "source": "encompass",
  "loan_number": "2026-03-0042",
  "document_type": "borrower_w2_2025",
  "attested_at": "2026-03-11T21:00:01Z",
  "signature": "tsig_sig_01JTQY8QK6X4YF7M6T2P9A5D3H",
  "policy_profile": "mortgage_loan_file_integrity_v1"
}

---

Integration Fit

TrustSignal sits behind the system that collected the artifact.

Layer	What Stays in Place
Evidence collection	Your existing platform (Encompass, Drata, or internal collector)
System of record	Unchanged - TrustSignal adds to it, not replaces it
Review workflow	Existing compliance or audit process
TrustSignal	Attests at ingestion. Signed receipt travels with artifact.

No workflow replacement required. Integrates at clear API boundaries.

---

Receipt Model

const auditReadyReceipt = {
  receipt_id: "tsig_rcpt_01JTQY8N1Q0M4F4F5T4J4B8Y9R",
  source: "encompass",
  loan_number: "2026-03-0042",
  document_type: "borrower_w2_2025",
  event_type: "income_document_received",
  artifact_hash: "sha256:93f6f35a550cbe1c3f0b5f0c12b9f0d62f3f9c6f8c6a4eddd8fa1fbfd4654af1",
  timestamp: "2026-03-11T21:00:00Z",
  receipt_status: "signed",
  verification_status: "match",
  policy_profile: "mortgage_loan_file_integrity_v1"
}

---

Documentation

Resource	Link
Developer Overview	trustsignal.dev/docs
Verification Lifecycle	trustsignal.dev/docs/verification
API Overview	trustsignal.dev/docs/api
Security Model	trustsignal.dev/docs/security
Architecture	trustsignal.dev/docs/architecture
Threat Model	trustsignal.dev/docs/threat-model

---

Claims Boundary

TrustSignal provides:

• Signed verification receipts
• Verification signals
• Verifiable provenance metadata
• Later integrity check capability

TrustSignal does not provide:

• Legal determinations
• Compliance certification
• Fraud adjudication
• Replacement for the system of record

---

Security

Public documentation does not expose proof internals, signing infrastructure specifics, or internal service topology.

For security review materials: trustsignal.dev/security

To report a vulnerability: info@trustsignal.dev

---

Pilot Access

Operational access and private verification workflows are restricted to TrustSignal pilot review.

→ Request a lightweight pilot

---

Contact

trustsignal.dev · info@trustsignal.dev

Source of Truth

This repository is the source of truth for its documented scope.