Skip to main content
OmniSentient · Reference

Trust & Security Center

Institutional documentation. Verifiable. Versioned. Source-of-truth for the OmniSentient platform.

Live document Calculating reading time…

Security Policy

OmniSentient — Security Policy

Version: 1.0
Last Updated: February 23, 2026


1. Our Security Philosophy

OmniSentient is a security-first platform. We apply the same forensic rigor to our own infrastructure that we provide to our customers. Our security model is built on:
- Tamper-Evidence over security theater
- Transparency over obscurity
- Verification over trust

We do not claim to be unhackable. We claim to be auditable.


2. Technical Verification & Proofs

OmniSentient provides institutional-grade verification protocols to prove our security claims.
- Verification Guide: Independent protocol for cryptographic proof of integrity.
- Forensic Spec: Deep dive into tamper-evident data structures.


3. Public Key Infrastructure (PKI)

All evidence exports are signed using our Ed25519 platform key.
- Identity Key: provenance_public_key
- Verification Method: Follow the protocol in the Asymmetric Provenance guide.


4. Responsible Disclosure (Bug Bounty)

If you discover a security vulnerability in OmniSentient, we ask that you follow responsible disclosure:

  1. Do not publicly disclose the vulnerability before we have had 90 days to respond and patch.
  2. Do not access, modify, or exfiltrate customer data beyond what is necessary to demonstrate the vulnerability.
  3. Do report the vulnerability to: security@omnisentient.ai
  4. Do include a clear description, reproduction steps, and impact assessment.

We will acknowledge your report within 48 hours and provide a status update within 7 business days.

We appreciate responsible researchers and will acknowledge contributions in our changelog.


3. Scope (What Is In Scope)

  • omnisentient-bot.vercel.app (production frontend)
  • /api/* endpoints
  • GitHub App webhook handling
  • Authentication and session management
  • Database access controls (RLS policies)
  • Cryptographic signing implementation

4. Out of Scope

  • Denial of Service (DoS) attacks
  • Social engineering of OmniSentient staff
  • Third-party services (Supabase, Vercel, Stripe) — report to them directly
  • Vulnerabilities requiring physical access to infrastructure

5. Our Security Controls

5.1 Application Layer

  • CSRF token enforcement on all state-mutating requests
  • Prompt injection protection on all AI analysis inputs
  • Rate limiting on webhook and API endpoints
  • Input validation and output encoding

5.2 Database Layer

  • FORCE ROW LEVEL SECURITY on all forensic tables
  • Append-only incident_events ledger (no UPDATE/DELETE)
  • SHA-256 forward hash chain enforced by PostgreSQL trigger
  • Role separation: auditor, admin, viewer roles

5.3 Cryptographic Layer

  • Ed25519 asymmetric signatures on all forensic exports
  • Canonical JSON serialization for deterministic signing
  • Key ID versioning for rotation traceability
  • Roadmap: HSM/KMS-backed signing keys (Phase K, revenue-triggered)

5.4 Infrastructure

  • TLS 1.3 for all data in transit
  • AES-256 encryption at rest (Supabase-managed)
  • GitHub App installation-scoped JWT tokens (no long-lived PATs)
  • Zero-trust webhook signature verification (HMAC-SHA256)

6. Incident Response SLA

If OmniSentient itself experiences a security incident:
- Detection → Acknowledgment: ≤ 4 hours
- Customer Notification: ≤ 72 hours (GDPR Article 33 compliant)
- Root Cause Report: ≤ 14 business days post-resolution


7. Security Certifications (Roadmap)

Certification Status
SOC 2 Type I Planned — revenue-triggered
SOC 2 Type II Planned — post Series A
ISO 27001 Future — enterprise contract driven
FedRAMP Future — government market entry

8. Contact

Security team: security@omnisentient.ai
PGP key: Available on request.

Found something missing or unclear? Tell us — every page is auditable and editable.

Back to home