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.
Editorial analysis by NHI Mgmt Group, based on content published by Pillar Security: “Untrusted Project-Local Filters in RTK: When Your AI's Eyes Are Someone Else's to Control”.
Key questions
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 attacker-controlled preprocessing layers create risk even when they never execute code?
A: Because the risk is perceptual, not just executable.
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
- Audit output-shaping tools in AI review pipelines Inventory every filter, hook, plugin, and preprocessor that can change what an AI assistant sees before it reviews code or scanner output.
- Require explicit trust for repository-local settings Block automatic loading of project-supplied configuration until a reviewer has validated origin, content, and intended scope of influence.
- Separate review evidence from repository content Preserve a raw, unfiltered path for security findings, diffs, and command output so the assistant cannot be shown a curated subset only.
Bottom line: RTK's project-local filters created a trust gap because repository content could shape what an AI assistant was allowed to see during code review.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 23 hours ago by NHI Mgmt Group
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
11/06/2026 1:17 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
12/06/2026 2:51 am
Trust laundering is the real failure mode here: the repository was allowed to supply perceptual authority, not just configuration. That assumption was designed for content that was safe to load automatically because it only changed local behaviour. That assumption fails when the content can hide evidence from an AI reviewer, because the reviewer now depends on the very file it is supposed to inspect. The implication is that AI-assisted review needs a stricter trust boundary around observation than around execution.
A few things that frame the scale:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: Should organisations treat filters, hooks, and plugins as supply-chain controls?
A: Yes. Anything that preprocesses code, logs, or scan output before AI review should be governed like a supply-chain control because it can suppress evidence or alter context. That means reviewing origin, enforcing change detection, and separating user-controlled settings from repository-controlled settings.
👉 Read our full editorial: RTK project filters exposed a new AI review trust gap
This post was modified 23 hours ago by NHI Mgmt Group