tierOf maps readOnlyHint: true → tier read, which is correct for "does it mutate" but wrong for "how dangerous is it". CIPP surfaced the gap: all 231 of its tools arrive annotated read-only, including ExecGetLocalAdminPassword (LAPS passwords), ExecGetRecoveryKey (BitLocker keys), ExecBitlockerSearch, ExecBreachSearch, ListBreachesAccount, ListBreachesTenant. Read-only, and yet handing any of them to a viewer effectively hands over the machine.
Those six were raised to destructive by hand (2026-07-29). That doesn't survive contact with reality: CIPP ships new endpoints regularly, and every upstream update silently drops fresh secret-returning tools into the read tier where every viewer sees them.
Proposal
- A small built-in list of sensitive name/description patterns (
password, recoverykey, bitlocker, secret, credential, breach, laps, apikey, token, …) that raises a tool's derived tier to destructive — applied in domain/catalog.ts next to tierOf, so it lands before policy sees the tool.
- An explicit
tier_override still wins in both directions, so an admin can lower a false positive.
- Surface it in the admin UI: show why a tier was raised (e.g.
destructive · sensitive-name next to the existing override, was read hint), otherwise the number looks arbitrary.
- Optional: deployment-extensible via
mspstack.config.json (sensitivePatterns) for house-specific naming.
- Log once per newly matched tool at discovery, so an upstream update that introduces a match is visible in the logs rather than silent.
Tests: pattern matcher unit tests (matches/false-positives), catalog integration (a read-annotated ExecGetLocalAdminPassword derives destructive), and the override-wins case.
tierOfmapsreadOnlyHint: true→ tierread, which is correct for "does it mutate" but wrong for "how dangerous is it". CIPP surfaced the gap: all 231 of its tools arrive annotated read-only, includingExecGetLocalAdminPassword(LAPS passwords),ExecGetRecoveryKey(BitLocker keys),ExecBitlockerSearch,ExecBreachSearch,ListBreachesAccount,ListBreachesTenant. Read-only, and yet handing any of them to a viewer effectively hands over the machine.Those six were raised to
destructiveby hand (2026-07-29). That doesn't survive contact with reality: CIPP ships new endpoints regularly, and every upstream update silently drops fresh secret-returning tools into thereadtier where every viewer sees them.Proposal
password,recoverykey,bitlocker,secret,credential,breach,laps,apikey,token, …) that raises a tool's derived tier todestructive— applied indomain/catalog.tsnext totierOf, so it lands before policy sees the tool.tier_overridestill wins in both directions, so an admin can lower a false positive.destructive · sensitive-namenext to the existingoverride, was readhint), otherwise the number looks arbitrary.mspstack.config.json(sensitivePatterns) for house-specific naming.Tests: pattern matcher unit tests (matches/false-positives), catalog integration (a read-annotated
ExecGetLocalAdminPasswordderivesdestructive), and the override-wins case.