privileged-legal-data

Privileged legal data

The single source of truth for the legal-sector data rules in this repo. The short prohibitions live in guardrails.md → "Privileged client data", which is always loaded; this skill is the depth behind them.

Deliberately model-invocable (no disable-model-invocation), unlike the review-* skills, so that a subagent can preload it via its skills: frontmatter or invoke it through the Skill tool. Change that and the reviewer agents lose their checklist.

The threat model

Not "leaking PII" in the generic sense. In a legal-domain system the harm is a confidentiality or privilege breach: two matters bleeding into each other, a client name in a log aggregator a third party can read, or privileged text pasted into a model prompt outside the engagement. Assume logs, traces, and error bodies are readable by more people than the matter is.

What counts as privileged

Anything that identifies a client or a matter, or that carries substantive content from either: client and counterparty names, matter or file numbers, case numbers and docket identifiers, the text of an instruction or advice, document contents and filenames, and free-text fields a user typed. An opaque internal id (a UUID with no external meaning) is not privileged; a "reference" that a human could look up is.

Boundary rules — Workers (worker-api, worker-*, queue-*, webhook-*, mcp-*)

• Validate before you touch it. Every body, query, and path parameter goes through a Zod schema from @repo/dtos-common at the boundary (zValidator). Use .strict() where the shape is closed so unexpected fields are rejected rather than forwarded into a log or a store.
• Logging. Log an opaque request id, a route name, a status, and a duration. Never a name, a matter reference, a document filename, or a request body. If you need to correlate to a matter, log the opaque id and resolve it in a system with the same access controls as the matter itself.
• Errors. onError and HTTPException return a generic message plus that request id. No stack traces, no internal paths, no echoed input, no upstream provider error text - upstream errors routinely quote the payload back.
• Cache keys and URLs. A Workers Cache key, a KV key, and a URL path or query string are all effectively logged infrastructure. Hash or use an opaque id; never embed a client name or matter reference. This applies to waitUntil writes as much as to responses.
• Tenancy. Matter isolation is a property of the query, not of the caller's good behaviour. Every read and write is scoped by the matter or tenant id the request was authorised for - derived server-side from the credential, never taken from a client-supplied field.
• Durable stores and queues. Anything written to KV, a queue message, D1, or an object store needs a stated retention and deletion rule in the owning app's AGENTS.md. A queue message is a copy of the data that outlives the request; treat enqueueing as a storage decision.
• Secrets. Only .dev.vars locally and wrangler secrets or env bindings in deployed environments. Never in wrangler.jsonc vars, never in a log, never in an error body.
• CORS and CSRF. An allowlist of known origins, never * in production; CSRF protection on state-changing /api/*. A permissive CORS header on a privileged endpoint is a disclosure bug, not a config preference.