Review the security boundary

Read SECURITY.md beside the code and deployed configuration. A security claim is incomplete when the configuration can quietly contradict it.

Trace one request across every boundary:

client → HTTPS/origin checks → token verification → MCP schema
       → handler authorization → notes backend → bounded result → logs

For each arrow, name the data, identity, permission, and failure behavior.

Inspect captured stdio diagnostics and platform logs. Search for note bodies, complete tool arguments, authorization headers, tokens, stack traces, and environment values. Remove them or document a narrow redaction rule.

Confirm these properties with tests:

• schemas bound input length and result count
• both handlers perform only reads
• backend credentials cannot write
• unknown IDs return safe tool errors
• untrusted note text remains labeled as data
• wrong-audience and wrong-scope tokens fail
• HTTP host and origin controls reject unexpected callers

Version 2 is the stable SDK line, but protocol and SDK updates can still change behavior. Pin the tested dependency versions, review release notes, and rerun the full matrix when upgrading.

Compare registered capabilities and deployment permissions with the original threat checklist. Delete unused registrations, secrets, bindings, network access, and compatibility paths.

Finish SECURITY.md with remaining risks. “Read-only” and “authenticated” are properties to verify, not reasons to stop reviewing.