LP1/LP3 remediation points at a permissions field that the Agent Skills spec does not define #300

LP1 and LP3 tell the user to add a permissions field to SKILL.md. The Agent Skills spec has no permissions field — following the remediation literally produces frontmatter the spec doesn't define.

The analyzer already knows this. _normalize_allowed_tools / _map_allowed_tools_to_categories exist precisely because allowed-tools is the Agent Skills equivalent, and node() reads both:

# mcp_least_privilege.py:234
# `allowed-tools` (Agent Skills standard) is also a permission declaration.
allowed_tools = _normalize_allowed_tools(manifest.get("allowed-tools"))

Only the user-facing strings are out of step.

Affected

LP2 and LP4 read fine — they talk about permissions generically without naming a field to add.

Why it matters

permissions is correct for an MCP server manifest; allowed-tools is correct for a SKILL.md. Since both flow through the same analyzer, the remediation reads as authoritative for whichever manifest was scanned — and for skills it points at a field that doesn't exist. In our case it sent us toward a spec-invalid edit before we checked the spec.

The spec field is a space-separated string, not a list, which is worth reflecting in any suggested snippet:

allowed-tools: Bash(python:*) Read Write

(The spec marks allowed-tools experimental.)

Suggested fix

Pick the wording from whichever manifest shape was scanned — the analyzer already has manifest in hand, so a permissions-vs-allowed-tools branch on the same signal that drives _map_allowed_tools_to_categories would cover it. Mentioning both fields in one string would also work and is a smaller change.

Happy to send a PR if you'd like — just say which shape you'd prefer.

Context

Found while gating a Rust project's vendored Agent Skills on skillspector scan --no-llm in CI. The LP3 finding itself was accurate and actionable — we filed anthropics/skills#1468 off the back of it. Only the remediation wording sent us the wrong way.