What the scanner looks for � and what the findings mean.
The point of the rules page is not marketing copy. It is to make the scanner legible before you trust it in a workflow or pay for Pro.
Config and launcher rules
Duplicate ids, weak transport, risky launchers, sensitive remote targets, and config shapes that deserve explicit review.
Secrets and auth rules
Credential-bearing URLs, obvious secrets, broad environment inheritance, token passthrough, and auth material that should not live in plain config.
Prompt and tool text rules
Prompt injection and tool-poisoning indicators that try to reshape model behavior or hide risky instructions in natural language.
Scope and blast-radius rules
Filesystem breadth, environment breadth, and setup choices that turn a bad server into a much bigger local problem.
Dependency hygiene rules
Missing lockfiles, unpinned dependencies, or install surfaces that make review and repeatability weaker than they need to be.
Severity and fix guidance
Every finding should return a rule id, severity, affected file, and a direct next action a developer can evaluate quickly.
Keep the output readable.
High-confidence issue that should block trust until it is fixed or intentionally accepted.
Material risk or review-worthy choice that deserves a decision before the setup becomes routine.
Context that helps you interpret the scan, including suppressions or nearby signals that change how you read the workspace.
The product should be inspectable even when you disagree.
Use the rules page and example report to judge whether a finding is useful. Local suppressions exist because the right output is not �always fail�; it is �make the tradeoff explicit.�