- LICENSE (MIT) + workspace license = MIT (down from MIT OR Apache-2.0) - Wiki-structure migration framework: V06 wiki_migrations table, WikiMigration trait, registry, and run_pending runner (registry starts empty; v1 ships per-project layout natively) - CHANGELOG.md, SECURITY.md, CONTRIBUTING.md - bin/release (fmt/clippy/test/deny/audit -> bump -> tag; never pushes) - .github release workflow + issue/PR templates - README: bootstrap example defers to default workspace/project - evals: inherit version/edition/rust-version from workspace Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2.6 KiB
Security Policy
Reporting a vulnerability
Please do not open a public GitHub issue for security vulnerabilities.
Report security issues by opening a private security advisory on GitHub. You will receive a response within 7 days. If the issue is confirmed we will aim to release a patch within 30 days and credit you in the changelog (unless you prefer to remain anonymous).
Threat model
ai-memory is a single-user, homelab tool. The following describes what the project is and is not designed to defend against.
In scope
-
Local data confidentiality. Wiki files and the SQLite database live under a single data directory controlled by the operating-system user who runs the server. We rely on filesystem permissions; no additional encryption at rest is provided in v1.
-
Network exposure when binding to non-loopback addresses. If you run
ai-memory serve --bind 0.0.0.0:…you are exposing the MCP and admin routes to your local network. Protect this with:AI_MEMORY_AUTH_TOKEN/ai-memory generate-auth-token(bearer token checked on every request).- Firewall rules or a reverse proxy with TLS.
The server logs a loud warning if it detects a non-loopback bind without a configured auth token.
-
Host-header DNS rebinding. The HTTP server enforces an
AI_MEMORY_ALLOWED_HOSTSallowlist (defaulting to127.0.0.1andlocalhost). Requests with aHostheader not in the list are rejected with 403. -
Request body size. Inbound HTTP bodies are capped at 10 MB to prevent trivial memory exhaustion.
-
Per-project isolation. Wiki files and SQLite rows are namespaced by
(workspace_id, project_id). A purge operation for project A cannot delete files that also belong to project B.
Out of scope for v1
- Multi-tenant authentication and authorisation. There is one bearer token (or none). There are no per-user roles or per-project ACLs.
- Encryption at rest. The data directory is a plain filesystem tree.
- Remote sync security. If you push the wiki git repository to a remote, securing that channel is your responsibility (SSH keys, GitHub access controls, etc.).
- MCP tool-call injection via agent output. The privacy strip
(
Sanitizer) removes obvious credential patterns from hook payloads, but it is not a comprehensive injection fence. - Denial of service. The server is not hardened against a malicious local actor hammering it with requests.
Supported versions
Only the latest release receives security fixes. We do not backport to older minor versions.