mitigations: add SAF-M-44 Tool Definition Integrity Monitoring

[Santoshkumarpuppala]

Closes the SAF-M-44 gap reported in #221. @fkautz — you said you were willing to take submissions on this, so here it is.

What this is

SAF-M-44 is referenced but has never existed. techniques/SAF-T1201/README.md listed it as "Tool Integrity Monitoring" among that technique's mitigations until the 2026-09-02 reauthor, and mitigations/SAF-M-45/README.md:233 still links it today as part of the chain it defers content safety to. Both 404.

This adds the document. The gap it fills is narrow and, as far as I can tell, uncovered:

SAF-M-45 establishes origin. It does not establish stability. A server in possession of its own signing key can sign a changed descriptor perfectly well, and the signature verifies. So a validly-signed replacement of a tool a human approved on the strength of its earlier description passes SAF-M-45 and is exactly the case SAF-T1201 describes. SAF-T1201 already names "content pinning and reapproval" as a preventive control (README.md:178) with no mitigation document behind it — this is that document.

I checked before writing: no existing mitigation covers descriptor drift as its subject. SAF-M-45 mentions pinning twice but is about signing; SAF-M-51 is embedding anomalies; SAF-M-53 is behavioural monitoring of what a tool does, where this is about what a tool declares.

On the name

The one surviving reference (SAF-M-45:233) calls SAF-M-44 "Behavioral Monitoring". I've written it as Tool Definition Integrity Monitoring instead, for two reasons: that was its name in SAF-T1201 before the reauthor, and "Behavioral Monitoring" would substantially overlap the existing SAF-M-53. Happy to rename if you'd rather keep the SAF-M-45 wording and have this be something else — say the word and I'll redo it.

Three things I noticed in SAF-M-45's chain while cross-checking

Not fixed here, since they're outside this PR's scope, but worth flagging — the "Combine with Existing Controls" block at SAF-M-45/README.md:230-235 is broken on all four entries:

link	says	actually
SAF-M-37	Metadata Sanitization	Token Rotation and Invalidation
SAF-M-38	Schema Validation	PKCE Enforcement
SAF-M-43	Steganography Scanner	404
SAF-M-44	Behavioral Monitoring	404 — this PR

The block closes with "This layered approach ensures both authenticity (who published it) and content safety (what it contains)", and none of the four links currently supports the second half. Happy to open a separate PR for the two mislabels and SAF-M-43 if that's useful.

Verification

• Written to mitigations/TEMPLATE.md, matching the format used by SAF-M-52/53/54. All 16 sections in TEMPLATE-CHECKLIST.md are present.
• Both code examples were executed, and assert what the prose claims — including the negative case, where an allowlist-style digest produces an identical hash across a flipped destructiveHint while an exclusion-style digest differs. That assertion is the finding, not decoration.
• Every cross-reference (6 techniques, 3 mitigations) was fetched and resolves to a document whose title matches how I've cited it. Given this PR exists because of dead links, it seemed worth not adding more.
• MCP field set checked against the 2025-06-18 schema: Tool carries name, title, description, inputSchema, outputSchema, annotations, _meta.

Disclosure

I maintain norviq, an Apache-2.0 policy enforcement point that implements tool-definition pinning, so I have a view on what this control should say and a bias worth knowing about. The document is written to the framework's threat model rather than to that implementation — the limitations section says plainly where pinning does not help, including trust-on-first-use and the fact that definition-only detection cannot see an unchanged descriptor over altered backend code.