A project-level AI configuration is becoming a critical security and collaboration standard for modern development teams. Even more, as a recent supply chain incident has shown that user-level AI settings can create unnecessary risk across every local repository on a developer machine. At the same time, a project-level AI configuration improves shared learning because useful AI rules, memory, and guardrails stay inside the repository, where the whole team can benefit.
At iits-consulting, we think in teams, not silos. Our slogan, “Innovation as a team,” is not just a nice phrase. It reflects how we work every day. We sell complete software development teams to our customers because strong results come from aligned collaboration, fast knowledge transfer, and shared responsibility. That is exactly why the discussion around project-level AI configuration matters so much. It is not only a security topic. It is also a team topic.
Recent reporting on the TanStack npm packages compromised in a supply chain attack made that especially clear. Once trust in developer tooling is abused, the impact can spread quickly. Therefore, teams need defaults that reduce risk and strengthen shared ownership at the same time.
A Project-Level Configuration Matters More Than User-Level Convenience
Many AI coding tools support several configuration layers. On the surface, that sounds flexible and even helpful. However, that flexibility can become a weakness when user-level settings quietly affect every repository on one machine.
That is the core problem. A user-level configuration does not belong to one project. Instead, it sits above all projects and can influence each of them. If such a configuration is manipulated, whether by malware, a compromised dependency, or simply a bad automation pattern, the impact is much broader than most developers expect. One unsafe rule in the wrong place can shape behavior across a complete local development setup.
A project-level AI configuration offers a much safer default. It keeps behavior close to the repository, reduces the blast radius of bad changes, and makes rules visible to the full team. In other words, it supports a cleaner trust model. Teams should also align that trust model with broader software supply chain security best practices.
The Security Risk of User-Level AI Configuration
The recent TanStack incident did not create this risk, but it did highlight it. Development tooling is now clearly part of the attack path. That means AI coding tools and their configuration deserve the same security attention as package managers, CI pipelines, and deployment credentials.
If user-level AI configuration is changed in a malicious way, the damage does not stay inside one repository. Instead, manipulated behavior can spread across every local project on a developer machine. Prompts may be influenced without being obvious at first. Memory rules can quietly be redirected. At the same time, configuration changes may happen without the rest of the team noticing.
That is why I see user-level AI configuration as a dangerous default for team-based repository work. It is too broad, too hidden, and too disconnected from reviewable project history.
A project-level AI configuration, by contrast, is easier to audit, easier to version, and easier to share. Most importantly, it keeps critical behavior where teams can inspect it together.
My Frustration With Multi-Level AI Configuration
Even before the recent supply chain attack, I already disliked the multi-level configuration model in Claude.
Using the Superpowers plugin, I follow a simple best practice. Whenever I detect a pattern of undesired behavior, I tell Claude to take a note so the same problem does not happen again and the preferred behavior is used instead. In theory, this is great. It turns one correction into a lasting improvement.
In practice, though, I often noticed that Claude preferred to store these takeaways in the user-level configuration instead of the project-level one. That immediately creates a drawback. Other developers working in the same repository do not benefit from those learnings. While the AI becomes slightly better for one person, the team stays where it was before.
As a result, I repeatedly have to stop the change, abort it, and explicitly tell Claude to put the new rule into the project scope instead. That is inefficient, but more importantly, it is the wrong default for collaborative software delivery.
This is exactly why a project-level AI configuration solves two problems at once. It reduces the security risk of overpowered user-level settings, and it makes useful improvements available to the whole team.
Supporting Team Learning
A strong engineering culture depends on visible learning. Good teams do not only produce code. They also capture decisions, sharpen conventions, and make lessons reusable.
That is where a project-level AI configuration becomes especially valuable. When guidance is written at the project level, the whole team benefits from the improvement. Corrected rules turn into team knowledge, while useful memory becomes shared context. Over time, refined workflows also become reproducible standards. Most importantly, this supports our company’s core principle: learning should stay visible, shared, and useful to the group.
Enforcing a Project-Level AI Configuration
In an internal Slack post I focused on a practical hardening approach. For a first step, the goal was simple: reduce the risk of user-level compromise while making project-level rules the preferred place for lasting improvements.
Verify User-Level Settings Before Every Prompt
The first measure is to verify the user-level settings file against a personally reviewed reference copy. If the current file differs from the verified version, the prompt flow should stop until a human checks the changes.
This adds friction in the right place. It does not slow down normal project work very much, but it does make silent manipulation harder. In a world of modern supply chain attacks, that is a sensible trade-off.
The principle is simple. Sensitive user-level AI settings should not change invisibly. They should be reviewed on purpose.
Prevent Access to User-Level AI Configuration
The second measure is to make the project explicitly deny reading from or writing to user-level AI configuration. This protects the CLI workflow from touching files outside the repository, especially because tool settings may be read before project instructions such as CLAUDE.md.
This is an important boundary. Project workflows should never be able to edit developer-wide AI settings behind the scenes. A project-level AI configuration only works as a trust model if the project scope remains clearly separated from the user scope.
Store AI Memory Inside the Project-Level
The third measure is about memory. In repository-based work, only project-level configuration and project-scoped memory should be allowed. Local or developer-specific memory outside the repository should be blocked for that context.
This matters for both security and teamwork. If AI memory is stored inside the project, it can be versioned, reviewed, improved, and shared. If it lives at user level, it becomes invisible team drift.
That is why I propose disabling user-level auto-memory for repository work, creating a local memory store inside .claude/memory/, and instructing Claude through project documentation to use only that location.
Likewise, similar instructions need to be be given for the user-level rules and user-level CLAUDE.md file. Additionally, those are to be verified against changes as well, just like the use-level settings. Consequently, any unverified change to those files needs to stop prompt flows as well.
That Setup Fits Remote Teams Especially Well
For remote teams, shared context is not optional. It is the basis of consistent execution.
At iits-consulting, around 160 people from more than 20 nations work together fully remote, and we have done so long before the Corona years. In a setup like that, hidden local differences can become surprisingly expensive. One person’s undocumented AI rule leads to one workflow, another person’s invisible memory leads to another, and suddenly the team is no longer aligned.
A project-level AI configuration is a simple way to avoid that drift. It turns guidance into something explicit, makes memory reviewable, and helps teams understand behavior more clearly. As a result, collaboration becomes more consistent across the whole project.
A project-level AI configuration also fits how we think about modern teamwork at iits-consulting. We believe strong delivery comes from shared responsibility, transparent collaboration, and resilient engineering practices. That mindset is visible in our blog content as well, for example in Top 1% Unternehmen in Deutschland mit Home Office, where remote-first culture plays a central role, and in Internal Developer Platform – Erfahrungen aus 100 Gesprächen, where scalable enablement and better team defaults are key themes. A project-level setup supports exactly that kind of environment because it keeps knowledge visible, reduces hidden local drift, and helps teams improve together instead of developer by developer.
Project-Level AI Configuration Should Become the Default
Security and collaboration are often treated as if they compete with each other. In this case, I believe the opposite is true.
A project-level AI configuration improves security because it reduces hidden cross-project risk. At the same time, it improves collaboration because it turns good corrections into shared team assets. The same design choice strengthens both sides.
That is rare, and it is valuable.
If AI coding assistants are now part of everyday software delivery, then teams need better operational defaults. They should verify sensitive user-level settings, block repository workflows from changing developer-wide configuration, keep memory inside the repository, and prefer project-level rules whenever improvements should benefit the whole team.
For me, that is the real takeaway. A project-level AI configuration is not just a workaround for one tool. It is a practical pattern for the AI coding era.
Final Thoughts on Project-Level AI Configuration
The recent attack only reinforced something I already believed: user-level AI configuration is too risky as the default place for durable behavior. It creates unnecessary exposure, and it keeps valuable improvements too private.
A project-level AI configuration solves both issues at once. It narrows the attack surface, and it turns personal learning into team learning.
That makes it a natural fit for the kind of work we believe in at iits-consulting: shared responsibility, visible knowledge, and innovation as a team.
For teams that want safer AI-assisted development without losing speed, this is a very good place to start.
