Summary
Propose a bidirectional crosswalk between SkillSpector's category/rule IDs and ATR (Agent Threat Rules), a separate open MIT detection ruleset for AI-agent attacks. Both tools emit SARIF 2.1.0 with ruleId and target the same SKILL.md threat surface (prompt injection, MCP tool poisoning, data exfiltration, privilege escalation, supply chain), so a category↔category mapping lets a user who runs one tool reason about the other's output, and — more usefully — surfaces coverage gaps in both directions.
This is interop, not a request to import or depend on anything. SkillSpector stays the engine; the crosswalk is a static reference artifact.
Why this is distinct from #221
#221 maps SkillSpector rules to an OWASP framework (AST10) — a checklist taxonomy. This is a different axis: a peer detection engine's categories, where each side has concrete rules and the diff is informative. A SkillSpector category with no ATR counterpart (or vice versa) is a real, actionable gap signal rather than a framework-coverage box.
Shape
- A
docs/ mapping table: each SkillSpector category (P1-P8, TP1-TP4, E1-E4, MCP LP1-LP4, AST*, SC*, etc.) ↔ ATR category, with full / partial / gap noted per direction.
- Gaps called out explicitly on both sides — that is the point, not coverage bragging.
- Optional, only if you want it: a non-normative
atr field alongside the existing rule metadata so a SARIF consumer can pivot. I would not push this unless you see value; the standalone doc is the low-friction version.
I am happy to draft the table against the current category set and open a DCO-signed PR if the direction is welcome. If you would rather keep external-scanner crosswalks out of the repo, a HOLD is completely fine and I will not push it.
Disclosure: ATR maintainer.
Summary
Propose a bidirectional crosswalk between SkillSpector's category/rule IDs and ATR (Agent Threat Rules), a separate open MIT detection ruleset for AI-agent attacks. Both tools emit SARIF 2.1.0 with
ruleIdand target the same SKILL.md threat surface (prompt injection, MCP tool poisoning, data exfiltration, privilege escalation, supply chain), so a category↔category mapping lets a user who runs one tool reason about the other's output, and — more usefully — surfaces coverage gaps in both directions.This is interop, not a request to import or depend on anything. SkillSpector stays the engine; the crosswalk is a static reference artifact.
Why this is distinct from #221
#221 maps SkillSpector rules to an OWASP framework (AST10) — a checklist taxonomy. This is a different axis: a peer detection engine's categories, where each side has concrete rules and the diff is informative. A SkillSpector category with no ATR counterpart (or vice versa) is a real, actionable gap signal rather than a framework-coverage box.
Shape
docs/mapping table: each SkillSpector category (P1-P8, TP1-TP4, E1-E4, MCP LP1-LP4, AST*, SC*, etc.) ↔ ATR category, with full / partial / gap noted per direction.atrfield alongside the existing rule metadata so a SARIF consumer can pivot. I would not push this unless you see value; the standalone doc is the low-friction version.I am happy to draft the table against the current category set and open a DCO-signed PR if the direction is welcome. If you would rather keep external-scanner crosswalks out of the repo, a HOLD is completely fine and I will not push it.
Disclosure: ATR maintainer.