Sensitive glob pattern

What mcp-scan saw

The AST scanner tested each argument for the literal substring /** and, in the same argument, one of .ssh, .aws, .gnupg, or .env. Both conditions must hold on the same argument string for the finding to fire.

Why it fires

A recursive glob rooted anywhere above a credential directory turns one path argument into read access over every key on the machine. Unlike a plain path grant, a glob's reach is not obvious from reading it, because the ** hides how deep it goes and the directory names it will cross.

When this is a false positive

• A deny or exclude argument has the same shape as a grant. --exclude=/Users/you/**/.env is protecting those files, and it matches the rule exactly.
• An ignore-file path passed as an argument, for example --ignorefile=/repo/**/.env-rules, contains both halves without granting anything.
• A documentation or help-text argument that quotes the pattern as an example of what not to do.

How to fix it

1. Read the argument quoted in the finding and determine whether it is a grant or an exclusion.
2. If it is an exclusion, this finding is safe to dismiss for that argument. The rule has no direction, so it cannot tell the two apart.
3. If it is a grant, replace the recursive glob with an explicit directory list. The server should be given the two or three directories it needs, not a root plus a wildcard.
4. Never leave a ** rooted at the home directory or above. Move the root down to the project directory even when the glob itself stays.
5. Re-scan. The rule needs both /** and a credential-directory name in one argument, so narrowing the root clears it.