# 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. Original AI-assisted SecNet educational content. Fictional local examples; not a standards provider publication, endorsement or compliance evidence. Page exercises do not create account progress. Sources checked: 2026-10-21 ## 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. ## 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. ## 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. ## 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. ## Working sequence 1. Map assets, actors and data flows. 2. Mark trust boundaries. 3. Describe abuse with prerequisites and impact. 4. Bind controls to tests and owners. 5. Refresh the model after design changes. ## 1. Does TLS solve everything? Encrypted transport does not prevent unauthorized object access. The model separately requires server session, object authority and tenant boundary. This code is a local policy model; it does not replace target/device testing. ### Weak implementation ```js s=>s.tls ``` ### Corrected implementation ```js s=>s.tls&&s.serverSession&&s.objectAuthorization&&s.tenantBoundary ``` ### Synthetic input and actual model output ```json { "before": [ { "name": "tls-only", "input": { "tls": true, "serverSession": false, "objectAuthorization": false, "tenantBoundary": false }, "expected": false, "observed": true, "matched": false }, { "name": "scoped-service", "input": { "tls": true, "serverSession": true, "objectAuthorization": true, "tenantBoundary": true }, "expected": true, "observed": true, "matched": true } ], "after": [ { "name": "tls-only", "input": { "tls": true, "serverSession": false, "objectAuthorization": false, "tenantBoundary": false }, "expected": false, "observed": false, "matched": true }, { "name": "scoped-service", "input": { "tls": true, "serverSession": true, "objectAuthorization": true, "tenantBoundary": true }, "expected": true, "observed": true, "matched": true } ] } ``` ## 2. A tool call requested by the model Even a model described as trusted cannot authorize an out-of-scope tool call. Bound tool authority server-side against user identity and impact. This code is a local policy model; it does not replace target/device testing. ### Weak implementation ```js s=>s.modelTrusted ``` ### Corrected implementation ```js s=>s.toolAllowlisted&&s.actorScope&&s.argumentsValidated&&s.approvalForImpact ``` ### Synthetic input and actual model output ```json { "before": [ { "name": "trusted-model", "input": { "modelTrusted": true, "toolAllowlisted": false, "actorScope": false, "argumentsValidated": false, "approvalForImpact": false }, "expected": false, "observed": true, "matched": false }, { "name": "bounded-tool", "input": { "modelTrusted": true, "toolAllowlisted": true, "actorScope": true, "argumentsValidated": true, "approvalForImpact": true }, "expected": true, "observed": true, "matched": true }, { "name": "overbroad-tool", "input": { "modelTrusted": true, "toolAllowlisted": true, "actorScope": false, "argumentsValidated": true, "approvalForImpact": true }, "expected": false, "observed": true, "matched": false } ], "after": [ { "name": "trusted-model", "input": { "modelTrusted": true, "toolAllowlisted": false, "actorScope": false, "argumentsValidated": false, "approvalForImpact": false }, "expected": false, "observed": false, "matched": true }, { "name": "bounded-tool", "input": { "modelTrusted": true, "toolAllowlisted": true, "actorScope": true, "argumentsValidated": true, "approvalForImpact": true }, "expected": true, "observed": true, "matched": true }, { "name": "overbroad-tool", "input": { "modelTrusted": true, "toolAllowlisted": true, "actorScope": false, "argumentsValidated": true, "approvalForImpact": true }, "expected": false, "observed": false, "matched": true } ] } ``` ## 3. A backup exists: can it restore? Backup presence is not recovery evidence. Independent identity, recoverable keys and a tested restore are required together. This code is a local policy model; it does not replace target/device testing. ### Weak implementation ```js s=>s.backupExists ``` ### Corrected implementation ```js s=>s.backupExists&&s.independentIdentity&&s.keyRecoverable&&s.restoreTested ``` ### Synthetic input and actual model output ```json { "before": [ { "name": "same-failure-domain", "input": { "backupExists": true, "independentIdentity": false, "keyRecoverable": false, "restoreTested": false }, "expected": false, "observed": true, "matched": false }, { "name": "tested-recovery", "input": { "backupExists": true, "independentIdentity": true, "keyRecoverable": true, "restoreTested": true }, "expected": true, "observed": true, "matched": true } ], "after": [ { "name": "same-failure-domain", "input": { "backupExists": true, "independentIdentity": false, "keyRecoverable": false, "restoreTested": false }, "expected": false, "observed": false, "matched": true }, { "name": "tested-recovery", "input": { "backupExists": true, "independentIdentity": true, "keyRecoverable": true, "restoreTested": true }, "expected": true, "observed": true, "matched": true } ] } ``` ## Exit evidence - Data-flow map with trust boundaries - Threat-control-test-owner register ## References - [OWASP ASVS 5.0.0](https://asvs.owasp.org/) - [NIST SSDF publications: 1.1 final; 1.2 draft](https://csrc.nist.gov/projects/ssdf/publications)