Vinculum — substrate memory for ai
why it existswhat it doesthe dashboardinstallpricing
githubsign in

security

How to report a vulnerability, what's in scope, and what you can expect from us.

last updated May 11, 2026 · source: content/legal/security.md

Security

We take security seriously. This page covers how to report a vulnerability, what we consider in-scope, and what you can expect from us.


Reporting a vulnerability

Email us at security@vinculum.run.

Please include:

  • A description of the vulnerability
  • Steps to reproduce (a proof-of-concept is helpful but not required)
  • The potential impact, as you see it
  • Whether you have disclosed it to anyone else

We will acknowledge your report within 48 hours and send a more detailed response within 7 days outlining the next steps and our assessment. We will keep you informed throughout the process.


Coordinated disclosure window

We follow a 90-day coordinated disclosure window:

  1. You report the vulnerability to us privately.
  2. We work to fix it within 90 days.
  3. After 90 days (or after the fix ships, whichever comes first), you are free to publish your findings.

If you need to extend the window or want to coordinate timing around a conference or publication, email us and we will work with you.

We do not threaten legal action against good-faith researchers. We do not require you to sign anything before disclosing to us.


In scope

The following are in scope for the coordinated disclosure program:

  • vinculum.run — the production web application and dashboard
  • MCP API — the tool surface at mcp.vinculum.run
  • Authentication flows — GitHub OAuth, session management, token handling
  • Multi-tenant isolation — access controls between projects and users
  • Data exposure — any path that would let one user read another user's entries or metadata

Out of scope

The following are not in scope:

  • Denial of service — rate limiting bypass, brute force, or resource exhaustion attacks
  • Social engineering — phishing, vishing, or pretexting targeting Vinculum staff
  • Physical security — attacks requiring physical access to servers
  • Third-party services — vulnerabilities in GitHub, Stripe, Cloudflare, Anthropic, or Voyage AI should be reported to them directly
  • Self-hosted instances — report vulnerabilities in the open-source codebase via GitHub Security Advisories
  • Known issues — issues already filed as public GitHub issues
  • Missing security headers not leading to a concrete attack path
  • Low-severity informational findings with no practical exploit path

What we ask of you

  • Do not access or modify data that is not yours
  • Do not disrupt or degrade the service for other users
  • Do not exploit a vulnerability beyond what is needed to demonstrate it
  • Do not publicly disclose details before the 90-day window closes or the fix ships

Verifying the vinculum-runner binary

The vinculum-runner daemon installed via curl https://vinculum.run/install | sh is a static Go binary cross-compiled from this repository. We do not currently use commercial code-signing certificates (Apple Developer ID, Windows Authenticode); instead, transparency is the trust model.

How the install script protects you

  1. The script fetches https://vinculum.run/install/runner.json over HTTPS to get the canonical SHA-256 for your platform.
  2. It downloads the matching binary from https://vinculum.run/install/runner-{os}-{arch}.
  3. It verifies the SHA-256 of the downloaded file against the manifest before marking the file executable. A mismatch aborts the install.

This catches MITM attacks, corrupted downloads, and tampered mirror copies.

Reproducing the build yourself

The runner binary is reproducible. Same Go version + same source = bit-identical output.

# 1. Clone at the commit your binary was built from (run `vinculum-runner --version` to find it)
git clone https://git.innervate.agency/steve-duskett/vinculum.run.git
cd vinculum.run
git checkout <commit-sha>

# 2. Build with the exact same flags
cd runner
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 \
  go build -ldflags="-s -w \
    -X main.Commit=<commit-sha> \
    -X main.BuildDate=<build-date>" \
  -o vinculum-runner-linux-amd64 .

# 3. Compare hashes
sha256sum vinculum-runner-linux-amd64
curl -fsSL https://vinculum.run/install/runner.json | jq .targets

The commit SHA and build date are embedded in the binary itself — vinculum-runner --version reads them out.

Live provenance manifest

/api/security/build-info returns the running server's git SHA, build timestamp, every runner binary's SHA-256 + size, and the trust-model status (in-flight Sigstore work, etc).

Roadmap

We are in the process of adding Sigstore keyless signing (cosign + Rekor transparency log) and SLSA Level 3 build provenance attestations via Forgejo Actions. When those land, every /install/runner-* download will have a co-published .sig and .intoto.jsonl that can be verified against the public Sigstore certificate authority — no shared secret, no commercial certificate, no trust in our infrastructure required.

This work is tracked publicly in the repository.


Hall of Thanks

Researchers who have reported valid, in-scope vulnerabilities under this policy:

No reports yet — you could be first.


Contact

security@vinculum.run — vulnerability reports

PGP key available on request. For non-security questions, see the Privacy Policy page.

Vinculum — substrate memory for aisubstrate live

Product

PricingDemoStatusChangelog

Resources

DocsQuickstartMCP IntegrationSelf-hostGitHub

Company

AboutSecurityPrivacyTermsCookiesAUPSubprocessorsDPAContact

Connect

GitHubX / Twittersteve@vinculum.run
v0.9·λx.x·Copyright 2026 (C) Whalefall Media, LLC