Threat modeling with forbidden-effect tests

The mechanism

A threat model begins with assets and authority. For ParcelOps, assets include incident data, user identity, approval records and the ability to write a note. Inputs include model-generated arguments, server descriptions, resource bodies and network metadata. Each crosses a different trust boundary.

State the attacker’s available control rather than assuming an all-powerful adversary. A malicious record author can change incident prose; a compromised server package can execute code inside its runtime; a buggy client can submit malformed requests. Controls appropriate to one case may not address another.

Translate claims into negative tests. “No unauthorized writes” becomes a fixture that tries a write without approval and asserts zero committed effects. “Private cache” becomes two authorized contexts requesting the same URI and receiving only their permitted data.

Worked example

This test matrix is proposed coverage. The offline capstone covers selected deterministic rows; transport and identity-system rows remain integration work. Keeping those statuses separate prevents a local toy model from becoming a false security certification.

Injection text -> no file read or upload
Foreign incident -> no private fields returned
Changed approval -> no write
Expired continuation -> no resumed operation
Header/body mismatch -> no handler dispatch
Cross-principal cache -> no result reuse
Unknown write outcome -> reconcile before retry

Practice: predict, inspect, explain

Offline exercise. Pick three rows and define an observable failure signal. Include the attempted operation, expected denial and the effect ledger after the attempt. Add a positive control so a test that denies everything cannot accidentally pass as a working system.

Expected observation: the evidence must show both intended capability and forbidden-effect prevention. Record limitations of mocks and fixtures. A passing synthetic test does not prove OS isolation, OAuth correctness or protection from every prompt-injection technique.

Troubleshooting and trade-offs

If a negative test asserts only an error string, inspect whether the handler already performed the effect. If a policy check occurs after a database write, the test must fail even if the final response says denied. Keep tests deterministic and target the actual enforcement function, then verify the wiring in integration tests.

Interview practice

Completion check

Write three negative tests with effect-ledger assertions and one authorized positive control.

Sources and version notes

This edition targets MCP 2026-07-28, checked 6 October 2026. SDK examples are version-sensitive and labelled when not executed. Synthetic fixtures are learning material, not protocol conformance evidence.

• Official documentation: Security best practices
• Official documentation: Local server security
• Official documentation: Security considerations