vinculumsubstrate memory for ai
  • How it worksThe substrate, end to end
  • The fieldParallel sessions, one memory
  • Mission ControlLive fleet telemetry
  • AI failure modesWhat we design against
  • Why it existsThe problem in one page
See the dashboardWatch a live fleet coordinate through one chat window.
Get started
  • QuickstartZero to first grunt
  • ArchitectureHow it's built
  • Self-hostingYour box, your data
  • API referenceEndpoints & tools
Connect your client
  • Claude Code
  • Claude.ai
  • Cursor
  • Cline
  • Zed
The specification
  • OverviewThe open memory spec
  • v0.1 specificationCurrent conformance spec
  • RevisionsHow the spec evolves
  • ContributingPropose a change
The encyclopedia
  • Substrate memoryThe definitional reference
  • vs. vector memory & RAGSimilarity vs. causality
  • The cost of keeping the thinkingCache vs. substrate economics
  • Why LLMs forgetThe intuitive entry point
The library
  • Browse recipesReady-to-run prompts, asks & gates
  • VerifiedCurated & safety-audited
  • CommunityShared by the field
Author
  • Standing OrdersRules every session follows
  • Safe by designFour-tier safety gates
  • Publish a recipeShare a workflow you trust
Hosted plans
  • Free$0 · solo demo, self-host free
  • Substrate$5/mo · hosted memory + dashboard
  • Pro$20/mo · spawn parallel workers
  • Team$100/mo · shared projects, SSO
More
  • EnterpriseOn-prem · SAML · SLA
  • Self-hostFree forever · AGPL v3
  • Compare plansFull feature matrix
Company
  • BlogField notes
  • ChangelogWhat shipped
  • AboutWho's building this
Trust
  • SecurityHow we protect data
  • StatusLive uptime
  • ContactTalk to us
sign in
  1. home›
  2. security

security

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

last updated July 27, 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://github.com/whalefall-media/vinculum.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.

vinculumsubstrate memory for ai
λx.xCopyright 2026 © Whalefall Media, LLC
substrate live

Product

PricingStatusChangelog

Resources

DocsQuickstartMCP IntegrationSelf-hostSubstrate memoryThe StandardGitHub

Company

AboutSecurityPrivacyTermsCookiesAUPSubprocessorsDPAContact

Connect

GitHubX / Twittersteve@vinculum.run