Skip to main content

Trust & Security

Security by Design.
Not by Declaration.

Every forensic record generated by OmniSentient is cryptographically verifiable, tamper-evident, and independently auditable.

Verified Versioned Tamper Evident
Status
Operational
Version 1.2
Last Review August 31, 2026
Public Key Ed25519 ↗
security.txt /security.txt ↗
  • Where does our code go?

    Dependency manifests only, by default.

    Automated remediation reads manifests, not source. Source is read and stored only if you switch on Code Intelligence, per repository.

    Privacy Policy →
  • Who else touches it?

    Four subprocessors, all named.

    Supabase, Vercel, Google Cloud and GitHub. What each one receives, and where it sits, is listed rather than summarised.

    Subprocessor Disclosure →
  • What happens if you are breached?

    72 Hours to notification.

    4 Hours to acknowledgement, 14 business days to a published root-cause report.

    Security Policy →
  • Can I prove any of this myself?

    Yes, offline, without asking us.

    Every forensic export is Ed25519-signed. The public key is published and the verification runs in seven lines.

    Verification Guide →
Encryption AES-256 Data at rest, Supabase-managed
Identity Ed25519 Forensic export signing
Transport TLS 1.3 All data in transit
Disclosure 90 Days Responsible disclosure window
Acknowledgement 48 Hours Vulnerability report response
Policy Version v1.2 Last reviewed August 31, 2026

Why We Are Trustworthy

Philosophy

Security is structural, not aspirational.

We do not claim to be unhackable. We claim to be auditable — and we can prove it.

Tamper Evidence

Every ledger row carries the SHA-256 hash of the row before it, written by a Postgres trigger. Altering or removing a row breaks the chain from that point on, and the break is detectable by anyone holding an earlier export.

Our own backend connects as the Postgres service role, which bypasses row-level security. We do not claim we cannot write to the ledger. We claim you can tell if we did.

anchor_incident_chain trigger on incident_events

Transparency

All system events — RBAC decisions, webhook verifications, AI analyses — are written to the hash-chained audit ledger with actor identity and UTC timestamp.

Exportable as signed CSV; auditors read it at /auditor

Verification

Our security claims are not self-attested. Every forensic export carries an Ed25519 signature you can check against the public key we publish.

Public key at /security/public-key

How It Works

From webhook to signed evidence.

Every step in the pipeline is cryptographically bound to the next. No gap, no bypass.

Independent Verification

Verify any report yourself.

You don't have to trust us. You can independently verify the integrity of every forensic export using standard cryptographic tools.

1
Export the ledger
Download a forensic export from your dashboard. It is a CSV, and the last four rows carry the manifest, its hash, the signature and the public key it was signed with.
2
Fetch our public key
Take the key from /security/public-key and compare it to the one embedded in the export. They must match. Verifying against the key inside the file alone only proves the file is self-consistent.
3
Check the signature
Any Ed25519 implementation will do. This one needs only the cryptography package.
import csv
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey

rows = {r[0]: r[1] for r in csv.reader(open("forensic_incidents.csv")) if len(r) == 2}
key = Ed25519PublicKey.from_public_bytes(bytes.fromhex(rows["# PROVENANCE_PUBLIC_KEY"]))
key.verify(bytes.fromhex(rows["# FORENSIC_SIGNATURE_ED25519"]),
           rows["# CANONICAL_MANIFEST"].encode())
4
Read the result
Silence means the signature is valid. A single altered character in the manifest raises InvalidSignature.
No output, exit 0

How We Operate

Implementation

What we've actually built.

Four layers of defense. Every control is verifiable — not aspirational.

CSRF Protection
Double-submit cookie pattern on all state-mutating endpoints. SameSite=Lax as secondary layer.
Rate Limiting
Per-IP and per-org limits on webhook ingestion and AI analysis endpoints.
Input Validation
All external inputs sanitized and validated before processing. Output encoding on all rendered data.
Prompt Injection Guard
Structured system prompts with boundary enforcement on all AI analysis inputs.
Force Row Level Security
FORCE ROW LEVEL SECURITY on incidents, incident_events, incident_notifications. Org scoping at both the query and database layers.
Append-Only Ledger
Restrictive RLS policies refuse UPDATE and DELETE to application sessions; with FORCE RLS and no permissive policy, deletion is denied by default.
SHA-256 Hash Chain
Each record includes the hash of the previous record, enforced by a PostgreSQL trigger.
Role Separation
auditor, admin, and viewer roles with distinct permission sets. Resolved from JWT claims only.
Ed25519 Signatures
All forensic exports signed using Ed25519. Signature covers canonical JSON serialization of the full report.
Canonical Serialization
Deterministic JSON encoding ensures signature is reproducible and immune to field-order attacks.
Key ID Versioning
Public keys are versioned with a key_id field. Rotation is traceable in the audit ledger.
Key Custody
Signing keys are held in environment configuration today. Migration to an HSM or cloud KMS is planned and not yet in place.
TLS 1.3
All data in transit encrypted with TLS 1.3. No support for legacy TLS 1.0 or 1.1.
AES-256 at Rest
Database encryption managed by Supabase. AES-256 for all stored data including audit records.
GitHub App JWT
Installation-scoped JWT tokens for GitHub API access. No long-lived PATs stored.
Zero-Write Policy
OmniSentient never force-pushes, merges, or commits directly. All remediation requires a PR + human approval.

Bug Bounty

Found something? Here's what happens next.

We take every report seriously. We acknowledge within 48 hours and credit researchers who help us improve.

Find Bug
Discover a potential vulnerability in OmniSentient.
Email Us
Send a report to security@omnisentient.ai with description, steps, and impact.
48h Acknowledgement
We confirm receipt and assign a tracking reference within 48 hours.
Review & Severity
Our team assesses impact, CVSS score, and affected versions.
Fix & Test
We patch the vulnerability and run regression testing.
Coordinated Disclosure
Published after fix is deployed. We credit you in our changelog if desired.

Incident Response

Response commitments.

These are contractual commitments, not aspirations.

Real-time
Detection
Automated alerting on anomaly signals
≤ 4 Hours
Acknowledgement
Incident confirmed, team assigned.
≤ 72 Hours
Notification
Affected organisations notified. GDPR Article 33 compliant.
≤ 14 Business Days
Root Cause Report
Full post-mortem published post-resolution.

Governance

Bug Bounty Scope

What is and isn't in scope.

Discover exactly what security research is eligible, what is excluded, and how to report findings responsibly.

In Scope
6 targets
Applications
Production Frontend
omnisentient-bot.vercel.app
Authenticated API Routes
/api/* — all protected endpoints
Infrastructure
Webhook Processing
GitHub App event ingestion pipeline
Database Access Controls
RLS policies and role grant enforcement
Cryptographic Signing
Ed25519 key and signing pipeline
Identity & Auth
Authentication & Sessions
JWT + cookie management
Out of Scope
4 exclusions
Infrastructure Restrictions
Physical Infrastructure
Requires physical site access
Third-party Services
Supabase, Vercel, Stripe — report to them directly
Non-Qualifying Reports
Denial of Service
DoS / DDoS attacks
Social Engineering
Attacks targeting OmniSentient staff

Certifications

Compliance roadmap.

Formal certifications are revenue-triggered. Controls infrastructure is already in place.

CERTIFICATION STATUS TARGET NOTE
SOC 2 Type I Planned Revenue-triggered Architecture audit complete. Awaiting formal audit engagement.
SOC 2 Type II Planned Post Series A Continuous controls monitoring infrastructure is in place.
ISO 27001 Future Enterprise contract driven ISMS policies documented. Formal certification enterprise-contract triggered.
FedRAMP Future Government market entry Relevant for US federal procurement. Not a current target.

Enterprise

Ready for procurement.

Documentation, architecture reviews, and vendor assessments available upon request.

NDA Available
Mutual NDA for security documentation sharing
Architecture Review
Full system architecture session for procurement
Security Questionnaire
CAIQ / custom questionnaire responses available
Vendor Assessment Support
We participate in your vendor security process

Contact

Report a Vulnerability

Found something?

security@omnisentient.ai
48 Hours Response time
90 Days Disclosure window
Available on request PGP key