Security & trust
This page is written for security reviewers. Wherever possible, the claims below come with a way to check them on your own hardware.
Last reviewed 2026-08-04. Product claims on this page restate what's already published on the changelog, features, and air-gapped pages.
Jump to: egress inventory · verify it yourself · controls · shared responsibility · assurance status · subprocessors · disclosure
The short version
- The product runs entirely on infrastructure you control. Indexing, embeddings, retrieval, and answers use local Ollama and local ChromaDB. No source code is uploaded, logged, or retained by us or any service we use. The one exception is opt-in on your side: a cloud-backed MCP client sends what it retrieves to its own vendor (see the egress inventory).
- There is no phone-home and no activation server. Licenses verify offline against a public key baked into the install.
- The Sentinel enforcement layer (Team and Enterprise tiers) gates every read with an access policy, scans every response and redacts the keys, tokens, and credentials it detects, and records each decision in a tamper-evident audit log.
- We do not yet hold a SOC 2 report or ISO 27001 certification. What we offer instead, for now, is verifiability: the section below lists what you can check yourself.
- Security disclosures: support@sourcevault.ai, never Discord or the public tracker.
Where things run
There are two systems to review, and they have different footprints:
- The product installs on your laptop, workstation, or a server you run, and includes the engine, index, models, dashboard, and MCP server. Everything it stores (source code, git history, embeddings, vectors, question-and-answer history, audit logs) lives in a local state directory and local ChromaDB on that machine. The optional high-scale history engine (Qdrant) is local software like everything else: version-pinned, checksum-verified, zero egress in operation.
- The vendor runs sourcevault.ai and its billing on ordinary web infrastructure, and holds ordinary commercial data: your purchase email, your license record, support correspondence. It never sees your code, because the product never sends it.
That split answers many standard questionnaire items at once: we never host, retain, or process your code. The sections below cover what remains: the controls inside the product, and the security of the small commercial surface we do operate.
The egress inventory
What the product sends over the network, complete as of the last-reviewed date above and confirmable with your own network monitor:
| Activity | Network egress | Notes |
|---|---|---|
| Answering questions, indexing, search, MCP responses | None | Local models (Ollama), local vectors (ChromaDB). Verifiable with a network monitor. |
| Cloning and syncing repositories | Fetches from your git host | Traffic goes only to the git hosts you configured: GitHub, GitLab, or Bitbucket. |
| Pulling models in the model manager | Fetches from the model registry | Model downloads happen at setup time. Air-gapped installs ship models in the Enterprise offline bundle instead. |
| License verification | None | Verified offline against a public key baked into the install. No phone-home, no activation server. |
| Caches (answers, history, models) | None | Three local caches, zero remote ones. Cached answers are re-sanitized on every hit where Sentinel is active (Team and Enterprise tiers). |
| Install and updates | Fetches the release and models | The one-command installers download from the network. Air-gapped environments use the Enterprise offline bundle instead; after install, nothing requires connectivity. |
| MCP with a cloud-backed client | Your choice | The MCP server is local-only, but a cloud-backed client sends what it retrieves to its own vendor. Inside a strict boundary, pair it with a local-model client. |
| This website | Cookie-less aggregate analytics | sourcevault.ai uses Vercel's cookie-less analytics. The product itself contains no analytics. |
Verify it yourself
Claims a reviewer can check independently:
- Run the product and watch the network. Answering questions requires no outbound connectivity at all.
- The Sentinel log is hash-chained with signed monthly anchors; edits, truncation, and outright deletion are detectable, and the operator console includes one-click chain verification. Verification works offline.
- Provenance attestations are signed, so you can check the AI-authorship and security-relevance classification on any commit yourself.
- The benchmark that produced our published numbers ships in every install, so you can reproduce the measurement on your own repositories.
- The engine is built directly on ChromaDB and Ollama, two open-source services you can read, with no orchestration framework in between and a dependency surface small enough to audit line by line. The engine itself is licensed software rather than open source.
For a formal evaluation, the Enterprise tier includes a compliance pack: a zero-egress verification procedure your security team runs themselves, plus signed compliance reporting over the Sentinel audit chain. It's scoped to your environment as part of an Enterprise engagement, so ask us.
Product security controls
Mapped to the control families a questionnaire will file them under. The Sentinel controls (access policy, DLP, audit log, provenance) ship in the Team and Enterprise tiers; the pricing page sells the bundle as the SourceVault Gateway. The rest are baseline in every install.
| Control family | What ships |
|---|---|
| Access control | The Sentinel access policy gates every reader: dashboard, API, and MCP all pass through the same check, so files your policy excludes are refused to each of them. Repo confinement adds path-escape and symlink checks plus file allowlists, keeping every read inside its repository. |
| Data loss prevention | A DLP pass scans everything leaving the engine (answers, search previews, file reads, MCP responses, and commit messages) and redacts the keys, tokens, and credentials it detects before delivery, with chunk boundaries stitched so a secret can't slip through split in half. At ingest, secret-bearing files like .env are excluded by default so credentials never become searchable vectors. |
| Audit logging | Every access decision lands in a hash-chained, tamper-evident log with signed monthly anchors. Edited entries, tail-truncation, and deletion of the log are all detectable, and logging fails closed rather than writing unprotected. The log records question text and file paths, deliberately not file contents, and lives in the local state directory with the rest of your data, so retention is yours to set. |
| Change provenance | Commits are classified for AI authorship and security relevance (path rules plus a pass over the diff itself) and recorded as signed, independently verifiable attestations. A drift correlator ties index drift back to the commits that caused it. |
| Authentication | The dashboard locks by default: no tokenless mode, a server-generated access token auto-provisioned at first boot, one-click session lock, and one-click token rotation that signs every other session out. A strict content-security policy and loopback guard keep the control plane local. |
| API security | Machine endpoints require HMAC signatures, with separate secrets per surface so one leak doesn't expose the whole stack. Every API surface is rate-limited, with limits mounted ahead of signature checks so brute-force attempts are throttled before any crypto runs. |
| Hardening | Error responses are sanitized: raw messages, paths, and upstream bodies go only to the server log. The Docker image runs non-root on a digest-pinned base, and the Linux installer shows a checksum and asks before executing rather than piping to a root shell. |
| Vulnerability management | Dependencies update on a weekly automated cadence on a current-generation stack, and the v1.5.1 release cleared every open npm audit finding, including high-severity advisories in transitive dependencies. |
| Data disposal | Deleting a repository is deliberate (typed confirmation) and complete: working copy, vectors, metadata, and indexed git history are all removed. |
| Release quality | A deterministic retrieval benchmark with real confidence intervals runs nightly against a committed baseline, so a regression is caught before it ships. |
Shared responsibility
Self-hosted software splits the duties between us and you:
The product provides
Everything in the controls table above, running on your hardware, plus the architectural property that makes the rest reviewable: your code never transits our infrastructure — a claim your own network monitor confirms.
You operate
- The state directory holds the index, caches, and audit log, and lives on the host you run. Encrypt that disk (FileVault, LUKS, BitLocker) as you would for the source code itself, and patch the OS on your normal cadence.
- For team installs, the Docker Compose deploy puts the dashboard and API on your network. Treat them as any internal admin surface: restrict them to the segments that need access, with your standard transport controls.
- The dashboard token and the per-surface API secrets are administrative credentials on your side of the line. Store and share them accordingly, and rotate the dashboard token from Settings when someone leaves.
- The product never checks in, so you schedule updates. Security-relevant fixes are documented release by release in the changelog; put it on your review cadence.
- Include the state directory in your backup policy if you want the index and audit history to survive the machine.
- Pairing the MCP server with a cloud-backed client sends what it retrieves to that client's vendor. You choose the client, so review its data handling before you pair one.
The company operates
- Release integrity: checksum-verified installers, digest-pinned container images, and the dependency and regression discipline described above.
- sourcevault.ai, checkout, and license issuance, the small commercial surface described in the subprocessors section below.
- Support and disclosure, through an email channel we answer (including for security reports) and a changelog that names the security-relevant fixes in each release.
Independent assurance
SourceVault does not yet hold a SOC 2 report, an ISO 27001 certification, or a third-party penetration test. If your procurement process requires one of those today, we'd rather tell you now than after your questionnaire.
Here is the posture in the meantime. The claims that matter most, zero egress and log integrity among them, can be verified without us, and they were designed that way on purpose: a verifiable control beats an attested one. A breach of our hosted systems exposes at most purchase emails, license records, and support threads; your code never transits them. The vendor-side risk that remains is release integrity, which is why installers are checksum-verified and container images are digest-pinned. If certification is a hard requirement for you, tell us.
Vendor data & subprocessors
What SourceVault the company holds about a customer: the purchase email, the license record, and support correspondence. Payment is handled by Stripe. Checkout happens on Stripe's hosted page, so card details never reach us; we hold the purchase record only. The services that touch that commercial data:
| Service | Role | What it processes |
|---|---|---|
| Stripe | Payments and checkout | Payment details and the purchase record. Card entry happens on Stripe's hosted checkout page. |
| Resend | Transactional email | License delivery and recovery emails to your purchase address. |
| Vercel | Website hosting and analytics | Serves sourcevault.ai; cookie-less, aggregate page analytics. No account, no tracking cookies. |
| Discord | Community support (optional) | Whatever you choose to post. Never use it for security reports or anything sensitive. |
No subprocessor processes your source code; the product never transmits it. The only path by which code could reach us or our vendors is you pasting it into a support message, so don't.
Reporting a vulnerability
Email support@sourcevault.ai directly; it's the channel we commit to answering. Please never report vulnerabilities in Discord or the public issue tracker. A machine-readable pointer lives at /.well-known/security.txt.
Reviewer FAQ
Does SourceVault have a SOC 2 report or ISO 27001 certification?
Not yet. SourceVault's compensating posture is verifiability: the product runs entirely on your infrastructure, sends nothing to us, and its central claims (zero egress, policy enforcement, log integrity) can be checked on your own hardware. Enterprise evaluations get a compliance pack with a zero-egress verification procedure your security team runs themselves.
Does our source code ever reach SourceVault the company?
No. Indexing, embeddings, retrieval, and answering all run on hardware you control, using local Ollama models and local ChromaDB. There is no phone-home and no activation server; licenses are verified offline. The vendor's data footprint for a customer is the purchase email, the license record, support correspondence, and cookie-less aggregate website analytics.
What data does SourceVault the company hold about customers?
Your purchase email and license record (payment handled by Stripe), transactional emails sent through Resend, cookie-less aggregate analytics on the website via Vercel, and whatever you send to support. None of those vendors sees your source code, because the product never sends it anywhere. The one way code could end up in this list is inside a support message you write, so keep it out of those.
How do we report a security vulnerability?
Send it to support@sourcevault.ai. Keep vulnerability reports out of Discord and the public issue tracker. A security.txt file at /.well-known/security.txt points to the same address.
Can our security team verify the zero-egress claim?
Yes. Run the product while watching the network: answering questions requires no outbound connectivity. The audit chain verifies offline, and provenance attestations are signed so they can be checked independently. The Enterprise compliance pack packages this as a runnable zero-egress verification procedure plus signed compliance reporting over the audit chain.
Which security controls are included in which tier?
The local-first architecture (nothing leaves your infrastructure) applies to every tier, as do the hardening baselines: locked dashboard, HMAC-signed machine APIs, rate limits, repo confinement. The Sentinel governance layer (access policy, DLP redaction, tamper-evident audit log, AI-change provenance) ships in the Team and Enterprise tiers, where the pricing page sells it as the SourceVault Gateway. Enterprise adds the offline bundle, signed compliance reporting, and the compliance pack.
Do you support SSO or per-user accounts?
Dashboard access is a server-generated access token rather than per-user accounts; there is no SSO or SAML integration today. Rotating the token from Settings signs every other session out at once. Team installs that need per-user identity in front of the dashboard typically add their own reverse proxy.
Running a security review?
Send us your questionnaire, or start with the free 7-day trial and put the product on your own network monitor — the fastest way to settle the questions this page raises. For regulated and air-gapped environments, the air-gapped page covers deployment and the Enterprise compliance pack.