Do not open a public GitHub issue for a suspected vulnerability.

Use one of:

• GitHub Security Advisories (preferred) — private report form at https://github.com/rohitg00/agentmemory/security/advisories/new. GitHub routes the report to the Maintainers, assigns a GHSA identifier, and keeps you in a private thread until the fix ships. All sensitive details (stack traces, credentials, exploit payloads) stay end-to-end within GitHub's security infrastructure — use this channel whenever possible.
• Encrypted email (fallback) — if GitHub is unavailable or the issue cannot be described in the GHSA form, send an encrypted message to ghumare64@gmail.com with subject agentmemory security. Encrypt with the Maintainer public keys published at https://github.com/rohitg00.gpg (PGP) and https://github.com/rohitg00.keys (SSH for verification); attach your own public key so we can reply encrypted. Plaintext email is accepted only as a last resort — prefer GHSA.

Include, at minimum:

• agentmemory version (npm view @agentmemory/agentmemory version against your install).
• The affected surface — REST endpoint, MCP tool, hook, CLI flag, or filesystem layout.
• A minimal reproduction — prefer one curl invocation or one MCP tool call plus the environment state required.
• Impact, in your own words.

1. Acknowledge within 72 hours (target: 24).
2. Triage — confirm reproduction, assign a severity using CVSS 3.1, and give you a rough timeline.
3. Fix in a private branch. Draft a GitHub Security Advisory with the patched version, CWE, CVSS vector, affected versions, and attribution to you (unless you prefer anonymity).
4. Coordinate disclosure — we agree a disclosure date with you. Default window is 30 days from acknowledgment for straightforward vulnerabilities, up to 90 days for ones that need a deep refactor.
5. Publish — release the patched version on npm, publish the advisory, update CHANGELOG.md under a ### Security section for the release, notify downstream scanners.

At v1.0 this policy switches to a stated LTS window per the roadmap.

In scope:

• The @agentmemory/agentmemory server (REST + MCP surface, hook handlers, state store).
• The @agentmemory/mcp standalone MCP server.
• The @agentmemory/fs-watcher connector.
• First-party integrations under integrations/ (hermes/, openclaw/, filesystem-watcher/).
• First-party plugin packaging under plugin/ (Claude Code, Codex CLI, GitHub Copilot CLI, OpenCode, Factory Droids).

Out of scope:

• Third-party MCP clients consuming agentmemory — report to those projects.
• iii-sdk upstream — report to the iii project.
• The marketing site under website/ unless the issue affects user security (XSS against visitors, credential leak in build output).

agentmemory stores durable state through iii-engine's file-based StateModule. The default runtime data directory is ~/.agentmemory/data, and the native state files are not encrypted by agentmemory before they are handed to iii-engine.

Deployments that require encryption at rest should put AGENTMEMORY_DATA_DIR on encrypted filesystem, disk, volume, or platform-managed storage and restrict directory permissions to the runtime account. Application-level encryption, per-tenant keys, encrypted export/import semantics, key rotation, and migration of existing plaintext stores are security and persistence boundary changes that require an approved design before implementation.

agentmemory ships pre-built artifacts in the npm tarball — dist/ is bundled at publish time, not built from node_modules at install time. The package's default runtime dependency tree is intentionally small (4 production deps: @clack/prompts, dotenv, iii-sdk, zod) plus an optional set guarded behind optionalDependencies for embeddings. The Claude Agent SDK fallback is an optional peer used only when explicitly installed and enabled with AGENTMEMORY_ALLOW_AGENT_SDK=true.

This fork commits pnpm-lock.yaml for source development and CI. Contributor builds and release jobs install with pnpm install --frozen-lockfile --ignore-scripts so tests, builds, and supply-chain scans run against the same resolved dependency graph without automatically running dependency lifecycle scripts.

The npm tarball still ships pre-built dist/ — fresh installs from the public registry don't compile from source, so npm/npx users consume the published artifact and SemVer dependency ranges as usual.

If you ship agentmemory inside a hardened pipeline that requires reproducible installs, the recommended path is:

1. For source builds from this fork, use corepack pnpm install --frozen-lockfile --ignore-scripts.
2. For deployments based on the published npm tarball, install in a controlled environment and create deployment-specific lock or shrinkwrap metadata that travels with your deployment.
3. Audit node_modules/ once at that point and republish internally.

CI installs from the committed pnpm lockfile with pnpm install --frozen-lockfile --ignore-scripts, so every test job builds against a fully resolved tree that is visible in review without automatically running dependency lifecycle scripts.

Supply-chain monitoring we already do:

• Dependabot opens PRs for every minor/patch bump on the production dep list (visible in the open PRs).
• Every PR runs the full test suite on ubuntu-latest + macos-latest, Node 20 + 22, before any merge.
• optionalDependencies (@xenova/transformers, onnxruntime-node, etc.) are guarded by try { await import("...") } catch so a missing or compromised optional dep cannot break the core runtime path.

If you find a malicious package in our dep tree, file via the GHSA flow at the top of this document — that's the fastest path to a fixed release on npm.

See the .github/security-advisories/ directory for advisory drafts. Published advisories (with assigned GHSA IDs) live at https://github.com/rohitg00/agentmemory/security/advisories.

Good-faith research, reported privately, does not get legal heat from the project. Research targeting third-party deployments of agentmemory is not covered — that's between you and the deployer.