TL;DR: AI coding assistants build context by reading the repo — and they read everything, including secrets and sensitive files, with no exclusion control. PainHunt's data shows developers asking for a ".gitignore for AI." A drop-in exclusion layer that governs what the assistant is allowed to see is a concrete DevTools wedge.
The evidence
DevTools / AI Coding Assistants surfaced as a high-quality cluster in the latest batch (4 posts scored 10+/15, average 12.1/15, intensity 7.5/10) across Mastodon, Medium, and GitHub Discussions.
Two reinforcing complaints define it. First, the assistant has no privacy boundary: developers report that the AI "reads everything, including potentially sensitive files," with no per-file or per-directory exclusion and no granular controls over what the tool can access in a repository. Second, the enterprise variant is sharper — teams with encrypted source and whitelisted-application policies report a CLI-based assistant that can't respect those boundaries, and a tool update that removed the safer editor-mediated path entirely, breaking the secure workflow.
The feature requests are specific: per-file and per-directory exclusion patterns in .gitignore-style syntax, workspace-level privacy policies, and selective context injection so the model only sees what it should.
Why this exists now
AI coding assistants got useful by reading more context — the whole repo, not just the open file. That made them powerful and, simultaneously, indiscriminate. The product incentive is to ingest everything; the developer's need is the opposite for a small but critical slice of files.
Secrets management already moved out of source (env files, vaults), but the AI assistant reaches around that by reading the working tree directly. So the same .env a team carefully kept out of git is now fair game for the model. The control surface that everyone assumed existed simply doesn't.
The wedge
Be the boundary the assistant doesn't draw for itself.
- A .gitignore-style
.aiignorethat the assistant honors — per-file and per-directory exclusion, dead simple to adopt. - Workspace privacy policies for teams: enforce exclusions centrally so an individual's config can't leak secrets into a prompt.
- An audit view: show what the assistant actually read on the last run, so the boundary is verifiable, not assumed.
Land on "your AI never reads your .env again," then expand into enterprise policy and encrypted-source support.
Risks and honest caveats
- Tool fragmentation: each assistant ingests context differently; honoring exclusions may require per-tool integration or sitting in the file-access path. Scope the supported tools honestly.
- Vendor may absorb it: the assistant makers could add native exclusion. The edge is being cross-tool and policy-grade for teams, not a single vendor's checkbox.
- False sense of safety: if the integration misses a path, secrets leak anyway — the audit/verification view isn't optional, it's the trust anchor.
How to validate this further
Read the AI-coding privacy threads in the Pain Point Browser, pressure-test demand with how to validate a startup idea, and check the exact wording in the Idea Validator. Related: a quality gate for AI-generated code and safety guardrails for LLMs connected to databases.