Security Policy

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:

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.
• System Architecture: Technical overview of the platform's security architecture and data flow.

3. Public Key Infrastructure (PKI)¶

All evidence exports are signed using our Ed25519 platform key.

• Identity Key: provenance_public_key
• Verification Method: See the Verification Guide for the full asymmetric provenance protocol.

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.

Public security advisories and patched CVEs are formally published via GitHub Security Advisories.

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

5. Our Security Controls¶

On the word "immutable". Application sessions cannot alter the ledger:
incidents denies UPDATE and DELETE, and incident_events denies UPDATE with
no policy granting it DELETE. Our own backend service role can still write to
those tables. That is why the hash chain exists and why we call the ledger
tamper-evident rather than tamper-proof — any edit or deletion, including
one made by us, breaks verify_incident_chain() and is detectable by you. We
would rather state that precisely than claim a guarantee we cannot enforce
against ourselves.

6. How We Handle Your Code and Your Data¶

Automated remediation analyses dependency manifests and does not ingest your
application source. The optional Code Intelligence feature does, and only when
you turn it on — that distinction is set out below and in the
Privacy Policy.

What leaves your repository, by default. Manifest files (package.json,
requirements.txt and equivalents), advisory metadata, and the surrounding
lines needed to write a version bump. Not your business logic.

What leaves it if you enable Code Intelligence. Source files you index —
.py, .js, .ts, .java, .go, .rs — are chunked, embedded and stored
so the chat feature can retrieve them. Indexing is per repository and is
triggered by a signed-in user, never automatically.

What reaches a model. Manifest content and advisory text are sent to Google
Gemini (us-central1) for root-cause analysis and fix generation. This is
transient: we do not store prompts at the provider, and the content is not used
to train any model. Prompt inputs are wrapped in an untrusted-input boundary
before they reach the model.

What we retain. Findings, audit ledger entries and evidence exports are
retained for 12 months, as set out in the Data Processing
Agreement. Ledger entries are hash-chained and are not deleted inside
that window.

Bring your own key. Enterprise customers may supply their own model key, so
inference runs against an account you control and under your own retention
terms.

The full list of subprocessors, what each one receives, and where it is
processed is on the Subprocessor Disclosure page.

7. 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

8. Our Own Supply Chain¶

We run the discipline we sell.

• Every pull request runs pip-audit against our dependency manifest. A new
  advisory fails the build; the audit gates the job rather than reporting into
  an artefact nobody opens.
• Every pull request runs the full test suite, including the boundary tests
  that pin tenant isolation, the write boundary, and the fail-closed behaviour
  of authentication.
• Container images are scanned with Trivy before they are pushed, and the
  deploy fails on a CRITICAL or HIGH finding with a fix available.
• The forensic ledger's chain is verified by verify_incident_chain(), which
  is the same verification we publish for customers in the Verification
  Guide.

We are a small team and say so plainly: there is no 24/7 SOC, and the roadmap
below is honest about what is not yet certified.

9. Security Certifications (Roadmap)¶

None of the following are held today. They are commitments with triggers, listed so the position is unambiguous.

10. Contact¶

Security team: security@omnisentient.ai

For encrypted communications, our public PGP key is provided to security researchers and enterprise clients upon verified request.

11. Revision History¶

See Also¶

• Data Processing Agreement
• Subprocessor Disclosure
• Privacy Policy
• System Status