Browse the documentation
Data handling and privacy
No telemetry and no silent self-update. The eleven flows of the npm package that can send data off your machine, each with what, to whom, when and under which consent, plus what stays local.
On this page
This page answers one question: what can BMAD+ send off my machine, to whom, and with whose say-so? The short answer: it has no telemetry and no silent self-update; eleven flows of the npm package can reach the network or start a program that does, and each is tied to a consent basis that you control. The list is not hand-written marketing: it is generated from a declaration in the registry, and before every release the continuous-integration job scans the shipped source and fails if a network call, a listener or a process start is missing from the declaration, or if a declared one no longer exists. The reference text is the Data handling section of SECURITY.md in the BMAD+ repository; this page mirrors it and explains how to read it.
Note What "through a started program" means
In the tables, "directly" means a BMAD+ script makes the request itself. "Through a started program" means BMAD+ starts a tool (npm, uv or pip, git, Codex CLI, Chromium, or a command you declared) and that tool does the sending. Downloading BMAD+ itself with npx is done by npm and is not one of the flows below.
The four consent bases
| Basis | Meaning |
|---|---|
| opt-out | It happens by default under the project policy, and you can turn it off. |
| opt-in | It never happens unless you ask for it with a flag, a confirmation or an explicit policy. |
| invocation | It happens only when you (or your assistant, at your request) run the command that does it, on input you supplied. |
| credential | It happens only once you have set the key (or URL) that the provider needs; without the credential nothing is sent. |
The eleven flows that can leave the machine
| Flow | How it leaves | What | To whom | When | Consent |
|---|---|---|---|---|---|
update-check (cli) | Through a started program | The package name and channel (npm view bmad-plus@latest) with npm’s request metadata: IP address, user agent (npm, Node.js and OS versions) and npm session headers. | registry.npmjs.org (the policy accepts no other registry) | bmad-plus update-check, which the generated adapters ask the agent to run once per session; the answer is cached in .bmad/update-check.json. | opt-out: bmad-plus update-policy --mode off stops every lookup. |
update-apply (cli) | Through a started program | The exact release requested, with npm’s request metadata, to download that version’s package. | registry.npmjs.org | bmad-plus update --latest --yes, or --auto when the project policy allows it. | opt-in: each run needs --yes, or policy mode auto with an explicit range. |
python-provision (cli) | Through a started program | The names and versions in the pack’s requirements.txt, with the installer’s request metadata; uv may also download a Python build. | pypi.org and files.pythonhosted.org, or the index configured for pip or uv on the machine; github.com (python-build-standalone releases) when uv downloads Python. | bmad-plus install --provision-python for a selected Python pack. | opt-in: only with --provision-python; without it no environment is created. |
nexus-worker (cli) | Through a started program | With codex-exec, the task’s instruction and input files (at most 1 MiB) go to Codex CLI, which sends them to the model provider of your own Codex login. With command, whatever that command sends. | The model provider configured in your Codex CLI; whoever a declared command contacts. | bmad-plus nexus launch on a plan with an explicit execution contract. | invocation: nothing starts without a plan you wrote and an explicit launch; shell, environment and arbitrary Codex flags are refused. |
nexus-verifier (cli) | Through a started program | Whatever the declared command sends; it runs with a minimal allow-listed environment. | Whoever the declared command contacts. | bmad-plus nexus verify on a task of a plan you wrote. | invocation: the command and its hash are fixed in the plan; a changed executable is refused. |
uat-page-results (core) | Directly | The run: tester name, step verdicts and notes. | The origin serving the page: bmad-plus uat serve on 127.0.0.1, or the claude.ai artifact store when the page is published as an artifact. | Each recorded verdict, when the page is served; a page opened from a file keeps results in the browser. | invocation: the tester chooses how the page is opened; a page opened from a file sends nothing. |
osint-providers (osint) | Directly | The investigation query (names, handles, keywords and URLs about the subject) and that provider’s API key, over verified HTTPS: the shared helper refuses any other scheme and any redirect off the provider’s host. | api.apify.com, api.exa.ai, r.jina.ai, s.jina.ai, deepsearch.jina.ai, api.parallel.ai, api.perplexity.ai, api.tavily.com, the Bright Data MCP URL you configure. | When the Shadow agent, or volley.py fanning out to the others, runs a provider script during an investigation. | credential: a provider is contacted only once its key (or Bright Data MCP URL) is set; the Phase minus 1 lawful-basis gate precedes profiling a named person. |
seo-site-fetch (seo) | Directly | HTTP requests for the audited site’s pages, robots.txt and sitemap, with the user agent the audit selects, from your IP address. | The site you ask to audit (public addresses only). | seo_fetch.py and seo_crawl.py, run by the SEO agents during an audit. | invocation: only the URL you give and its internal links are fetched; private, loopback and link-local addresses are refused. |
seo-google-apis (seo) | Directly | The audited URL or origin, and your GOOGLE_API_KEY in the x-goog-api-key header, never in the request URL; redirects are not followed. | www.googleapis.com, chromeuxreport.googleapis.com, searchconsole.googleapis.com | seo_apis.py, run during an audit’s performance phase. | credential: only when GOOGLE_API_KEY is set; without it the script returns an error and sends nothing. |
seo-screenshot (seo) | Through a started program | Chromium’s requests for the audited page and the resources its own host serves, with a browser user agent, from your IP address. Third-party resources are blocked, not fetched. | The site you ask to audit (public addresses only). | seo_screenshot.py, when an audit asks for screenshots. | invocation: only the URL you give, with the Playwright and Chromium you installed; non-public addresses, other hosts and redirects off the host are refused. |
assurance-checks (cli) | Through a started program | Whatever a declared check command sends; the CLI itself sends nothing. | Whoever a declared check command contacts. | bmad-plus assurance run on a case you wrote. | invocation: only the commands listed in your own case file run, and only on an explicit assurance run; the signing key is never passed to a check. |
Doing less, on purpose
| You want | Do this |
|---|---|
| No registry lookup at all | npx bmad-plus update-policy --mode off. The generated instructions then find that the check is off and continue the task. |
| Check without a request | update-check --offline: it starts no registry request and reports unknown. |
| No Python environment | Do not pass --provision-python. The SEO pack then works in prompts-only mode. |
| No data to a model provider through Nexus | Do not write a plan with codex-exec, and do not run nexus launch. The host-owned flow sends nothing itself. |
| No OSINT calls | Do not set a provider key. A provider is contacted only when its key is set. |
| No SEO traffic | Do not run an SEO audit, and leave GOOGLE_API_KEY unset to skip the Google APIs. |
| An acceptance page that tells nobody | Open the built page from a file instead of publishing it as an artifact: it keeps results in the browser and sends nothing. |
What stays on the machine
npx-launcher(cli): starts the CLI in the same Node.js executable, everynpx bmad-plusrun.python-health(cli): runs a pack environment’s own Python, isolated (-I), to confirm its modules import. When:bmad-plus doctoron a project with a provisioned Python pack.review-git(cli): reads the local repository with git (rev-parse, merge-base, diff, ls-files, show) to build a review scope.nexus-git(cli): reads the repository root and HEAD commit withgit rev-parsefor Nexus plans and runs.uat-serve(cli): serves a recipe page and stores its verdicts, listening on 127.0.0.1 only and refusing any other Host header.uat-release-gate(core): runs the project’s own bmad-plus CLI with the current Node.js to grade recorded acceptance runs, when the project runs the release-gate script.osint-install(osint): copies the OSINT agent and skills into a project, then runs the pack’s local diagnostic script with the system Python, when you run the package’s install script.
Maintainer services, not part of the package
The repository also holds two services that the maintainer deploys on his own servers: the Audit 360° MCP server (git, GitHub, Gamma, CI, RAG and memory tools for the maintainer’s agents, behind a bearer token and a password-protected dashboard) and the upstream monitor (it watches the BMAD-METHOD repository and notifies the maintainer). They are not in the npm package and users do not install them. Their own flows are declared the same way and checked by the same gate; SECURITY.md lists them in full.
Supply-chain and publication facts
- Seven runtime dependencies (
@clack/prompts,commander,design-skill,fs-extra,js-yaml,picocolors,semver).design-skillcontributes the skill files BMAD+ copies at install and a linker command that BMAD+ never runs. - Production dependencies are audited before each release; high and critical findings block publication. Maintained Python requirements are audited in CI and block publication on known findings.
- Secrets used by the project’s automation live in GitHub Actions Secrets, never in code; the local secrets directory is gitignored; the pipeline scrubs private directories before public distribution.
- npm packages are built from scrubbed distribution copies with no parent commit or source history. Each release keeps its CycloneDX production SBOM, archive and integrity manifest as workflow artifacts, and the registry integrity must match the checked archive before the website is deployed.
- Publication uses npm OIDC authentication. npm provenance is not enabled, because the private build repository and the distribution repository differ; an inventory or a hash is not a provenance attestation, and the project says so.
- Writes and deletions refuse symlinks and junctions. Credentials are never put in URLs (the Google key goes in a header). The acceptance page loads nothing from another origin.
Reporting a vulnerability
Use GitHub private vulnerability reporting: on the repository, Security tab, "Report a vulnerability" (report a vulnerability ). The report stays private between you and the maintainer. If you cannot use it, email l.rochetta@gmail.com with the subject [SECURITY] BMAD+ - Brief description. Include a description, steps to reproduce, an impact assessment, the affected versions and, optionally, a suggested fix. Do not open a public issue, do not exploit beyond a proof of concept and do not disclose before a fix is released. Valid reporters are credited in the changelog unless they prefer anonymity.
| Severity | Acknowledgment | Fix target |
|---|---|---|
| Critical | 24 hours | 72 hours |
| High | 48 hours | 7 days |
| Medium | 7 days | 30 days |
See also
- Trust and ownership Trust, ownership and licences
- Reference: update-check update-check
- Reference: update-policy update-policy
- Nexus and the process backend Nexus: autopilot, parallel work and durable runs
- FAQ Frequently asked questions