ZTARE is a local-first research workbench. Project Workbench includes a loopback HTTP service with filesystem-backed, state-changing APIs. It has no user accounts, session boundary, multi-tenant surface, or supported public endpoint. Conventional web-application threats apply to that local service in proportion to the authority of the user running it. The threats that do apply follow from the system's actual shape: it executes agentic code, ingests untrusted text into agent context, and asserts correctness through ledgers and pre-registered contracts that depend on integrity rather than confidentiality.

The Workbench API can edit project files and launch bounded CLI actions. Treat access to port 8765 as access to the repository under the server process's UID. It must remain bound to loopback. For a remote host, use the documented SSH tunnel; do not publish the port directly.

The public and allowlist project scopes prevent accidental project disclosure in a demo or shared screen. They are fail-closed inventory and path boundaries, not authentication. CORS is also not authentication. Run make forensic-workbench-release-check before a shared deployment to verify the built app, manifest boundary, hidden-project refusal, and local-origin policy. The supported commands and SSH-tunnel procedure are documented in docs/guides/workbench-release.md.

This document states the threats taken seriously, the assumptions the system already makes about its own integrity, and how to report something that breaks those assumptions.

ZTARE invokes LLM tool-use agents (Codex, Claude Code, role-bound daemons) that can read the filesystem, write files, run subprocesses, and call out to model APIs. There is no security sandbox between agent-emitted instructions and the local environment. Running this repo is functionally equivalent to granting a tool-using agent shell access to the workspace, with the additional property that the agent's behavior is sensitive to the contents of files it reads.

Assumption: the maintainer runs the workbench in an environment whose blast radius they accept (a dedicated user, a VM, a workspace machine). Running it on a host that holds production credentials, signing keys, or write access to shared infrastructure is out of scope and not supported.

ZTARE ingests Lean sources, mathlib snapshots, mined corpora, research papers, sampled web pages, and maintainer notes into agent context. Any of those paths is a vector for instructions that target the agent rather than the human reader. Inputs that look like data to a human read as instructions to a model.

Defenses already in ZTARE. Source-readiness labels mark which inputs are membrane-clean; observer/membrane boundaries restrict what an agent at a given role may act on; the local console is the adjudication path when a substrate is ambiguous; the Governance Gate (scripts/public/control/leanmill/governance_worker.py) is the only ratifier of proof-value credit and refuses unsourced promotion. These are correctness controls, not security controls, but they constrain how far an injected instruction can move before it hits a deterministic gate.

What breaks them: ingesting an unlabeled source as if it were membrane-clean, or letting an agent role write outside its declared scope. Report either as a defect.

The validator loop, the closure-claim governance discipline, the forecast pool, and the reflexive mining layer all assume their ledgers record what actually happened. Silent rewriting of analytics/public/ledgers/, the catch ledger, the prediction ledger, the trajectory archive, or rewriting git history on any branch the maintainer treats as canonical, defeats the central correctness guarantee. From the outside this looks like normal file editing; from ZTARE's perspective it is forgery.

The mitigations are structural rather than cryptographic: append-only ledger conventions, the pre-registered evaluation-harness contract with its contract_sha256 pin, separate publication-surface and working-surface trees, and an explicit non-destructive maintainer discipline (no force-push to chosen canonical branches, no --no-verify, no destructive git without explicit authorization).

Treat as a vulnerability: any path through ZTARE that silently mutates a ledger without leaving a corresponding event, any gate that promotes a claim whose review packet is not source-labeled, and any divergence between a pre-registered contract SHA and the file the runner actually executes.

The forecast pool's calibration value depends on forecasts being sealed before resolution: an observer who can read a resolved-but-not-revealed forecast file before the resolution window leaks ZTARE's own self-evaluation. The protection is filesystem layout and ledger hygiene, not access control. Anyone with read access to the host has access to these files; the discipline assumes the maintainer is also the forecast author.

A pull request, fork, or shared CI runner that surfaces sealed forecasts before resolution is a leak even if no key material moves.

The evaluation-harness contract at analytics/public/leanmill/dashboard_data/evaluation_harness_contract.json pins a contract_sha256 value that must match the file's actual content hash at run time. The eval-harness runner enforces this check and aborts on mismatch. A live mismatch currently exists (pinned 6fbdce…6e71a90, actual ed46ada5…); this is the system detecting post-registration edits, exactly the behavior the pin was added for. Maintainer reconciliation is pending; do not bypass the check with --skip-contract-sha-check for credited runs.

The deepest misuse is not a CVE. It is treating model-emitted prose as evidence of capability without deterministic-gate corroboration. The workbench is structured to make this hard (rubrics, gates, ledgers, falsifiers, demotions), but the discipline is maintainer-enforced. A fork that publishes a model's narrative as a validated result while stripping the gate/demotion machinery has not been hacked; it has broken the contract this repo describes. If you find a path that lets ZTARE publish such a claim without a demotion-on-failure recorded, report it as a defect.

• Internet-facing or multi-user deployment of Project Workbench. There is no authentication, authorization, rate limit, or tenant isolation for that use.
• Denial of service against a public endpoint; exposing one is unsupported.
• Archived workspaces, working-paper drafts, maintainer-only research state, protected directories, maintainer notes, or paths matched by .gitignore. These are working state, not the publication surface.
• Dependency CVEs in requirements.txt — track separately with pip-audit or equivalent; an alert there is upstream maintenance, not a ZTARE-specific vulnerability.
• The HTML demo under docs/landings/ — static, no scripts that touch workbench state.
• Cosmetic, broken-link, or doc-staleness issues — open a normal issue.

Use the private channel; do not open a public issue.

• Private GitHub Security Advisory: https://github.com/sparckix/ztare/security/advisories/new
• Email: sparckix@gmail.com

Useful in the report: the path through ZTARE you took, the file(s) or ledger(s) involved, whether you reproduced it, and whether it surfaced through normal maintainer use or required a crafted input. A working proof-of-concept is welcome but not required.

This is a single-maintainer research repository. There is no SLA, no bounty program, no triage team. The realistic commitment is: an acknowledgement within seven days, a written assessment (fix, document as known, or rule as out of scope) within thirty, and a reporter credit in the resulting commit and DECISION_LOG.md entry unless the reporter prefers anonymity. Coordinated disclosure for issues that might affect downstream forks is preferred over silent patching.