HARBOR DESK / 08 / PRACTICE GUIDE
Threat modeling and design review
Give architecture boxes meaning through trust boundaries and abuse paths. Review API, mobile, AI tools and recovery dependencies in the same product.
Download guide and workpapersOriginal AI-assisted SecNet educational content; examples are fictional. Not a source organization publication or endorsement. Sources checked: 2026-10-21.
CODE REVIEW DESK
See the decision through the test.
Code here is a local policy model with no target connection. Passing model cases are not security approval or device tests.
Does TLS solve everything? / Weak code
Inspect an incomplete decision based on record existence or another positive signal. Consider denial cases alongside permitted use.
s=>s.tlsEncrypted transport does not prevent unauthorized object access. The model separately requires server session, object authority and tenant boundary.
Choices and outputs last only on this open page; they do not update account progress, career status, points or certificates.
01 / EXPLANATION
From data flow to abuse
First state what is protected and which actors may do what. Browser/mobile, API, record store, AI assistant and backup are separate trust domains. On each arrow, mark who authenticates, which fields are untrusted and what authority is delegated. TLS protects transport; it does not decide object ownership or tenant authority.
02 / EXPLANATION
AI tools and impact boundaries
User documents and ticket text may be untrusted data. Do not treat a model’s tool-call suggestion as authority. Apply tool allowlists, server actor scope, argument schemas and human approval for impactful actions. Prompt filtering alone cannot replace these controls. Interpreting tool output as new instructions introduces another boundary failure.
03 / EXPLANATION
Recovery belongs in the model
A backup deletable through the same admin identity shares the attacker’s failure domain. Assess identity separation, key recoverability and actual restoration together. Describe threats through prerequisites, impact, control, owner and verification test rather than likelihood slogans. Update the model when design changes; an annual diagram is not evidence for an evolving system.
04 / EXPLANATION
Harbor Desk abuse record
The asset is another customer’s support ticket. The attacker starts with a normal account, and the entry point is an API accepting a ticket identifier. The threat is crossing tenants by changing that identifier. The control is a server tenant-and-owner predicate; verification is a negative test using the same local identifier in another tenant. The API team owns the control, with same-revision test output as evidence. If an AI assistant calls tools from ticket text, add a threat for text requesting broader authority and bind tools to the same server actor. This is more useful than “encryption exists” because it links attack prerequisites to controls and tests.
Build the evidence yourself.
Blank workpapers are not completed tests. Fill them in your authorized environment without secrets or real personal data.
Full guide with code, outputs and reasoning ↓Primary references
Explanations are authored by SecNet. References support method and platform context; verify current editions and organizational policy for real use.