Report security issues privately through GitHub's "Report a vulnerability" flow on this repository, or by email to the maintainer address listed on https://helios-it.nl. Please do not open a public issue for an unpatched problem.

We aim to acknowledge a report within three working days.

GuardSkill runs on directories that are, by assumption, hostile. Everything it reads — config values, path names, script contents — is attacker-controlled input, and the report it prints is an output channel an attacker would like to influence.

• It only reads the project it inspects. No file there is created, modified or deleted. The only file it writes is the report you ask for by name with --out.
• It never executes anything it finds. Values from config and hook scripts are treated as text: printed as evidence, never run, never passed to a shell.
• It never asks a server anything. The agent-settings class reports remote MCP servers that declare no credential material. That is a statement about the file, not about the server: no connection is made, and the finding says so in its own words. Whether an endpoint really requires authentication is a question this tool deliberately cannot answer.
• The directory walk does not follow symlinks, and neither does config reading. A config file that is a symlink, or whose resolved path leaves the scanned tree, is refused, reported, and marks the scan INCOMPLETE. The file is not read, so a delivered directory cannot point the scanner at ~/.gitconfig and have its contents printed.
• No network access. No outbound connections, no telemetry. Identical behaviour offline.
• No dependencies. Nothing is installed alongside it.
• No single file can drown the report. At most 50 findings per rule per file are listed; the rest are counted in one summary finding, and the scan says it is not listing everything. A settings file with 15,000 hostile entries otherwise produced a 21.8 MB SARIF document, and GitHub refuses an upload above 25,000 results or 10 MB — so the Security tab would have shown nothing at all. A finding that cannot reach the person reading it is the same failure as not finding it.
• One bad file costs its own finding and nothing else. A settings file that is unparsable, too large or nested past the limit is reported and marks the scan INCOMPLETE, and the failure is contained to that file. A run that has already found a payload cannot be turned into "nothing to report" by putting a second, harmless-looking file next to it — suppressing a scanner is cheaper than evading one, and that route is closed.
• A file it cannot read is a finding, not a pass. A config or hook script that exists but cannot be opened is reported and marks the scan INCOMPLETE. Silence about a file that was never read would be the one failure mode a scanner cannot have.
• Bounded traversal and bounded reads. Depth and entry count are capped; a config above 4 MB is reported rather than parsed. A walk that stops early is reported as INCOMPLETE, never as clean.
• The report cannot be rewritten by its subject. Control characters are stripped from every field before it reaches a terminal or a Markdown file — values, paths, titles and explanations alike. A directory called vendor<ESC>[2K\rNo findings cannot erase the line it appears on. The JSON output keeps raw values, because it is not a terminal, with the escape character itself escaped.

If you find a way to make GuardSkill write, execute, connect out, escape its target directory, or print something that misrepresents what it found, that is a vulnerability in this tool and we want to hear about it.

Every behavioural claim in the README, this file, SKILL.md and the project page appears below with the test that proves it. A claim without a test is removed from the documentation rather than left standing.

These are known and deliberately not closed in 0.4.0. They are listed here because an accepted risk that is not written down publicly is not accepted, it is concealed.

• Four executing config keys are out of scope: sendemail.smtpServer, instaweb.httpd, ssh.variant and the HTTP proxy settings. Reasons per key in rules/git-exec-keys-inventory.md. Each is reachable only through a command a coding agent does not run, or names something other than a program.
• The real-world corpus is reconstructed, not cloned. The five fixtures reproduce shapes observed in an independent review, not verified checkouts pinned by commit SHA. See test/corpus/PROVENANCE.md. A reconstruction cannot surprise you the way a real checkout can.
• Detection stops at git configuration and agent settings. .vscode/tasks.json, CI workflow definitions, npm lifecycle scripts and TOML-based agent settings are not inspected, each with a reason in rules/agent-settings-inventory.md. Naming them keeps the gap a decision rather than an oversight.
• The remote MCP check is a declaration, not a probe. mcp-remote-no-auth reports that a server entry carries no credential material in the file. A server that requires authentication but is configured elsewhere will still be reported, and a server that declares a header but accepts unauthenticated requests will not be. Answering it properly means connecting, and the no-network promise is worth more than this check.
• Agent settings in TOML are not inspected. .codex/config.toml and anything else in that format needs a TOML parser, and a scanner with no dependencies is not taking one on for a single format. Listed in rules/agent-settings-inventory.md with the other out-of-scope entries.
• One parser deviation remains, on valueless keys. key with no = is treated as the string true, because a rule has to evaluate something; git treats it as boolean true. Every other case in the golden table now matches git config --file byte for byte. Listed with reasons in test/golden.test.js.