version: "1.0.0" name: threat-and-scale-check description: Check trust boundaries, scale behavior, and layered safety. Use when handling user input, external API responses, files, or auth; when designing permissions, validation, or any safety mechanism; when data volume could grow; or when writing loops that touch I/O. Also use when reviewing whether a single safeguard is the only thing standing between a mistake and a disaster.

Trust Boundaries · Scale · Layered Defense

Trust boundaries — where does "external" start

Draw the line between "what I control" and "everything else."

• Are you trusting user input, external API responses, or file contents as-is? Does it flow unescaped into SQL, shell commands, file paths, or HTML?
• Are passwords, API keys, or tokens exposed in code, logs, or error messages?
• Does this action need a permission check? Are you trusting a client-supplied "I'm an admin" claim?
• Is validation enforced at only one point (client-side only, or a DB constraint only)?
• Environments are a trust boundary too, not just people and networks: does this code (or test) assume something is present that isn't guaranteed everywhere it runs? Concrete case (Hncs): CI has no image data — raw_calib_cache/ and downloaded_samples*/ exist locally but aren't committed, so a test that reads from them passes on a laptop and fails (or silently skips) in CI. The fix is the same shape as any trust-boundary fix: mock the decode layer or unit-test the pure logic, don't let the untrusted/unavailable environment leak into what the test depends on.
• Principal angle: does this trust boundary cross a service or team line? A gap here isn't just a local bug — it's a contract other teams inherit and copy.
• Distinguished/Fellow angle: would a breach of this boundary be the kind of incident that ends up as a company-wide postmortem or a public disclosure — and does the fix need to hold up as doctrine for years, not just survive this quarter's traffic?
• Executive angle (CTO/VP-Eng): does a breach of this boundary carry regulatory exposure, contractual liability, or customer-trust damage the board would need briefed on — not just an engineering incident to remediate.

Scale — 10x / 1000x

Working fine at 100 records today proves nothing.

• Does this approach still hold if data grows 10x, 1000x?
• Is there a DB query or network call inside a loop? (N+1)
• Is everything loaded into memory at once? Can it be streamed or batched?
• But don't optimize without measuring first — confirm the bottleneck is actually here before touching it.

Layered defense

A structure where the next layer catches a failure is more realistic than betting everything on one perfect defense.

• If this safeguard fails, is it an immediate incident, or is there another layer behind it?
• Block unconscious mistakes, allow conscious choices, but leave a trace — that's the shape of a good safeguard. Block everything and people route around it; allow everything and it becomes an incident.
• Verify on success too. Don't stop at "it was blocked" — confirm why it was blocked, and whether that holds in other conditions.