What does IH-MCP-002 flag?
Flags a literal secret written into the env block of an MCP server in a configuration file.
- A key such as API_KEY, TOKEN or SECRET in an env block whose value is a literal string.
- Known token shapes, such as a GitHub personal access token prefix.
- Not reported: a reference such as ${API_KEY}, an empty value, and ordinary settings like LOG_LEVEL.
Why it matters
A literal API key or token in a config file is copied onto disk, into backups and repositories, and into the server process. Anyone who can read the file can use the key.
Examples
Illustrative shapes with placeholders in angle brackets. They show what the rule looks at; they are not runnable and not taken from real malware.
Can IH-MCP-002 fire on a safe skill?
- A throwaway demo value that only looks like a secret.
- A non-secret identifier stored under a key whose name contains TOKEN.
How do I fix an IH-MCP-002 finding?
- Remove the value from the file.
- Pass the name of an environment variable that you set outside the config file.
- Rotate the secret if the file was ever shared or committed.
CLI guidance: Remove the value and pass the name of an environment variable the operator sets outside the config file.
How do I tune or allow IH-MCP-002?
Prefer fixing the config. If a value is a harmless placeholder, a config suppression with a reason, or ignoreGlobs for that one file, keeps the rule on everywhere else.
Every key is described in Configuration. To print this rule from the CLI, run ironheights rules show IH-MCP-002.
What can IH-MCP-002 miss?
- Secrets stored under unusual key names or encoded.
- Secrets in files that are not MCP configs; other rules cover those shapes.
- A secret that was already committed. Scanning does not rotate it.
No finding means no rule matched. It is not proof of safety. Files larger than 1 MiB are skipped without being read; the verdict is then incomplete, not no findings, but the file is still not checked. See Limitations.
Related rules
ironheights rules list.