Notifications
Clear all
Topic starter
09/06/2026 11:47 pm
TL;DR: RTK’s project-local filters let repository content control what Claude Code could see, creating a medium-severity path to hide backdoors and suppress scanner output before review, according to Pillar Security. The deeper issue is trust laundering: if the observation layer is attacker-shaped, AI-assisted code review cannot be treated as a reliable control.
NHIMG editorial — based on content published by Pillar Security: Untrusted Project-Local Filters in RTK, a review of how repository filters can hide evidence from AI coding assistants
By the numbers:
- RTK’s maintainers responded within 24 hours and shipped a fix.
Questions worth separating out
Q: What breaks when project-local AI filters load automatically from a repository?
A: Automatic loading breaks the assumption that the reviewer sees the same evidence the repository contains.
Q: Why do repository-supplied filters create trust problems for AI coding assistants?
A: They let untrusted content inherit trusted authority simply because it is stored in the expected project path.
Q: How do security teams know whether AI review outputs are actually trustworthy?
A: Teams need to validate the integrity of the entire observation chain, from repository files to the model’s context window.
Practitioner guidance
- Inventory AI preprocessing layers Map every filter, hook, plugin, and configuration file that can change what an AI assistant sees before it reviews code or scanner output.
- Require explicit trust for repository-supplied config Block automatic loading of project-local filter files unless a user has reviewed the exact contents and opted in for that repository.
- Verify the review path, not just the model answer When a clean AI review conflicts with code smell, scanner output, or diff context, inspect the transformation layer that fed the model.
What's in the full article
Pillar Security's full research covers the operational detail this post intentionally leaves for the source:
- The exact RTK filter-loading paths and the trust boundary logic that made project-local configuration authoritative.
- The proof-of-concept attack flow showing how hidden code and suppressed scanner output changed model judgement.
- The patch mechanics, including the warning flow, hash-based trust revocation, and explicit opt-in commands.
- The disclosure timeline and version details needed for remediation tracking and internal change records.
👉 Read Pillar Security's analysis of untrusted project-local filters in RTK →
Project-local AI filters: is your review pipeline trustworthy?
Explore further
10/06/2026 2:16 am
Project-local AI filters are an observation control, not a convenience feature. RTK showed that anything sitting between repository output and model context becomes part of the security boundary. When that layer can be controlled by repository content, the assistant is no longer reviewing the codebase directly. Practitioners should treat preprocessing, filtering, and transformation rules as governance objects, not developer preferences.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when untrusted project configuration changes what an AI assistant sees?
A: Accountability sits with the team that allowed repository-local configuration to auto-load without explicit trust controls. Governance frameworks such as OWASP NHI and zero trust both point to the same principle: provenance, review, and revocation must be part of the control design, not an afterthought.
👉 Read our full editorial: RTK project filters exposed a new AI review trust gap
