This addendum to the design review models what could go wrong in the design, using STRIDE per element. Each process, data store and external entity in the data flow diagram is checked against the STRIDE categories that apply to its kind. Each flow that crosses a trust boundary is checked for tampering, disclosure and denial of service. Risk is likelihood times impact, each rated low, medium or high.
Scope
- In scope: the proposed deployment: development on the homelab (P1 to P4), and the public MCP endpoint that P5 adds (flow F4). The statuses below describe that design, not any system as it runs today.
- Out of scope: Anthropic's own systems, beyond what this design sends them. Also the laptop's operating system, and the homelab's physical security and other workloads.
- Assumptions: every source is open data read anonymously, and nothing private enters the system. The operator is trusted, and the tailnet is the network perimeter.
What it protects
| Asset | Why it matters | Where it lives |
|---|---|---|
| Correct joins and honest records | They are the product's whole claim: an answer can be trusted and rerun | the planner, the crosswalks, the records |
| The experiment's integrity | A flattering result would be worse than none | questions, gold answers, graders, transcripts |
| Credentials | Each one spends money or compute, or reaches a system | the Anthropic credential, the slurmrestd key, Harbor's push credential, SSH keys |
| The homelab's availability | A small cluster has little memory headroom | Slurm, k3s, the shared filesystem |
| Images | Every answer names the image it ran in | Harbor: OCI images and SIF files |
| Licence terms | The ABC Atlas and MouseLight are non-commercial | every record |
Data flow diagram
The five trust boundaries, from the outside in:
- The internet: every byte from a data source or an upstream package is untrusted content.
- Anthropic: prompts, transcripts and tool results go there by design. Managed Agents calls in from there in P5.
- The laptop: the operator's machine. Claude Science and Claude Code act for the operator, under the agent's direction.
- The homelab cluster: answers on the tailnet only, and holds the credentials.
- The agent partition: runs code that an agent wrote, as an unprivileged user with no credentials. It is the innermost and least trusted zone, since anything an agent was steered into runs here.
Threats
Each threat has one of five statuses:
- In the design: the design review already carries the mitigation.
- Platform control: a control of the platform the system is deployed on carries it.
- Verify in P1–P4: the mitigation is designed, and a check in P1 to P4 confirms it.
- Open: the mitigation needs a design change or a decision.
- Accepted: a residual risk, kept on purpose with its reason.
What the model changes
Of the 56 threats, 27 are open. Those with high risk are T-03, T-08, T-16, T-21, T-25 and T-26. The open threats call for the changes below.
- Records are written by the server. Agent code holds no credential for the records store. The MCP server writes each record from the job's outputs, and run_plan returns no table unless its record is written. Records are append-only and addressed by their own sha256 (T-26, T-39, T-51).
- The cache is read-only to agent code. A trusted staging step fills it, and every entry is checked by its sha256 on read (T-25). A size quota with least-recently-used eviction keeps it from filling the shared filesystem, and a miss falls back to reading in place (T-40).
- Egress goes through an allowlisting proxy. The proxy checks bucket names, since an allowlist on S3's regional endpoint admits every bucket in that region (T-24). It also paces requests to each data source, so the sweep's reads do not look like abuse (T-43). The login node gets the same allowlist (T-16). The runner reaches Anthropic's API and nothing else (T-07).
- The login node is untrusted. Claude Science runs commands there directly, outside any container, so the node holds no credentials and has no admin rights (T-16).
- Slurm gets limits and a memory of what ran.
- QOS limits on the agent and harness partitions, throttled job arrays, and memory as a consumable resource (T-21).
- Job scripts kept in accounting, and session ids in each job's comment (T-02, T-20, T-28, T-47).
- Other users' jobs hidden (T-50).
- Clients authenticate.
- A token per client on the MCP server (T-09, T-54).
- On the public endpoint: a token per harness, a quota on run_plan, traces without argument values, and records visible only to the caller that made them (T-03, T-45, T-52).
- The supply chain is pinned, signed and traceable.
- Lockfile hashes, base images pinned by digest, a scan in CI, signed images and SIFs, and a job prolog that checks each SIF's sha256 (T-08, T-34, T-44).
- Each OCI image carries its source revision label, and the pipeline number is stored with the image and its SIF (T-49).
- Nodes cache SIFs by sha256, so a job whose SIF is cached still runs when Harbor is down (T-55).
- The experiment is kept apart from agent code.
- Gold answers and graders sit on paths no agent job can reach (T-42).
- Transcripts are scanned for the credential before they are stored (T-29).
- The runner lets the agent run code only on the agent partition (T-30).
Questions for reviewers
- Empty cells: The coverage grid marks with a dot each category that applies to an element but has no threat recorded. Which of them hide a real threat?
- The kernel trade-off: Apptainer shares the host's kernel (T-23). Is that acceptable for a v1 that holds no private data and no credentials on agent nodes?
- The login node: Should Claude Science's commands on the login node (T-16) run in a container too, or is an unprivileged account with narrow egress enough?