Encode Trust Boundaries So Hardening Effort Follows the Real Threat, Not the Maintainer's Own Inputs #2501

Problem

Agents and the review bot apply the same adversarial hardening to every input, whether the input comes from an outside attacker or from the maintainer. Effort is spent defending against threats that cannot happen, and each review round generates more of it.

The maintainer has corrected this repeatedly, and so far the correction lives only in per-repo session memory, which does not carry between repositories or sessions. Two recent examples:

• Blog. The maintainer hands a session an image to process, and the session files a run of image-parser hardening issues as though the image were hostile upload content. The maintainer has asked the Blog sessions to stop many times.
• HomeAutomation-Config. A healthcheck change that reads docker and cscli output back from the maintainer's own VPS went through an adversarial review brief that treated that output as hostile. The result filters the text, quotes only a fixed status vocabulary, and adds a test case proving that hostile text is not quoted. The VPS is not an attacker, so none of that defends against anything real.

Hub-side, the same pattern shows up in issues that harden the guard against command shapes no real session produces. Re-ranking those is out of scope here. The rule below gives every session, and the reviewer, a way to tell the difference.

Proposed rule

A GOVERNANCE.md section, carried fleet-wide and packaged as a skill or folded into agent-conduct / fleet-code-review / pr-review-conduct. Proposed working title: "Trust Boundaries and Hardening Effort".

1. Every input belongs to one of two classes, and the class decides the effort.
   • Trusted: the maintainer and what the maintainer controls. Files, images, and data the maintainer hands a session. Settings and secrets files the maintainer writes. CLI arguments. The repository's own content and the hub's. The maintainer's own hosts, and the output read back from them over SSH or a local command. State files the repository's own scripts write.
   • Untrusted: what arrives from outside. Requests from internet clients and every field they control (headers, paths, bodies, the access-log lines they produce). Upstream release metadata and downloads that end up in a config file or a command line. Third-party API responses. Content from outside contributors. Bot-generated pull requests.
2. For trusted input, the only threat is a maintainer mistake. Guard against the realistic mistake (a typo, CRLF line endings, a missing file, a wrong unit) only where it would fail silently or destructively. Use one check at the point of read with a clear message, centralized rather than repeated per site. Do not build parsers for adversarial shapes, test injection through a trusted file, filter text read back from the maintainer's own hosts, or file issues for hypothetical attacks on trusted input.
3. For untrusted input, validate at the boundary where it enters, once, proportionate to what it can reach.
4. Effort follows likelihood times consequence. A finding about an impossible or non-exploitable case gets declined, not fixed and not filed. A finding about an unlikely mistake with a loud failure gets declined too. A finding is worth a fix PR or an issue only where the case can actually occur and its failure would be silent or destructive.
5. A review finding asking for hardening against a trusted input is declined, citing this section, with no fix PR and no issue. This goes into .github/copilot-instructions.md too, so the reviewer stops raising these findings rather than sessions declining them every round.
6. Each repository names its own boundaries. A short list in its own operations doc (for example OPERATIONS.md) naming which concrete inputs are trusted and which are not, so a session or reviewer applies the rule without re-deriving it. A repository whose list is missing defaults to the classes in point 1.

Done when

• The section is in hub GOVERNANCE.md and routed from the AGENTS.md table.
• A skill surfaces it at the decision moments: briefing a review, triaging a finding, and about to file a hardening issue.
• .github/copilot-instructions.md carries the reviewer half (point 5).
• The carried change reaches the fleet on the next resync.

Filed from a HomeAutomation-Config session at the maintainer's request.

🤖 Generated with Claude Code