Project-local configuration is settings stored in a repository and loaded automatically by tooling during work on that codebase. It is useful for shared behaviour, but it becomes risky when loaded without provenance checks, because attacker-controlled settings can inherit authority they were never meant to have.
Expanded Definition
Project-local configuration refers to settings checked into a repository and loaded automatically by developer tools when they operate in that codebase. In NHI and agentic workflows, that often includes build flags, lint rules, environment presets, task definitions, and tool-specific policy files that shape execution context. The key security distinction is that the configuration is not merely descriptive; it can influence what commands run, what secrets are read, and which identities or tokens tooling can reach.
Definitions vary across vendors on whether a project-local file is “code,” “policy,” or “configuration,” but the operational risk is consistent: local trust can become inherited authority. That makes provenance, review, and change control essential, especially when tooling auto-discovers files without a human approving them first. The NIST Cybersecurity Framework 2.0 is useful here because its governance and access-control outcomes map cleanly to configuration trust decisions.
The most common misapplication is treating repository-local settings as harmless convenience, which occurs when auto-loaded files are allowed to alter tool behaviour without review or source verification.
Examples and Use Cases
Implementing project-local configuration rigorously often introduces review overhead and workflow friction, requiring organisations to weigh developer speed against the risk of untrusted settings silently changing execution.
- A repository contains an editor or IDE config that auto-enables task execution; a malicious pull request changes the task to exfiltrate a cloud token from the developer environment.
- A build tool loads a project-local file that defines package registries and install hooks; if provenance is not checked, a poisoned configuration can redirect dependency resolution.
- An agentic coding assistant reads workspace-scoped instructions and tool permissions from the repo, so a compromised branch can broaden the agent’s tool access beyond what the maintainer intended.
- A CI pipeline consumes project-local variables for deployment targets; an attacker who can alter the repository may cause the pipeline to publish artifacts to an unauthorized destination.
- Repository-level policy files are used to standardise linting and secret-handling behavior, but only if paired with branch protection and code review. Guidance in the Ultimate Guide to NHIs shows how configuration sprawl often becomes a secrets-exposure path when teams rely on convenience over control.
For tooling patterns that rely on automatic context loading, the issue is not the file format itself but whether the runtime treats repository content as trusted input. That concern aligns with broader identity and authorization guidance in the NIST Cybersecurity Framework 2.0 and with identity-bound execution models used in modern software delivery.
Why It Matters in NHI Security
Project-local configuration becomes an NHI issue because software agents, CI runners, and developer tools often act with non-human authority: they can read secrets, sign artifacts, call APIs, and trigger deployments. If a repository can modify the settings that govern those actions, the repository itself becomes part of the attack surface. This is especially important when secrets are stored outside a secrets manager, because configuration files then become a direct route to credential exposure.
NHIMG data shows the scale of that exposure: 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, and 79% have experienced secrets leaks, with 77% of those incidents causing tangible damage, according to the Ultimate Guide to NHIs. Those figures matter because project-local configuration is one of the easiest places for privileged settings to accumulate unnoticed.
Governance should require provenance checks, restricted auto-loading, and explicit separation between harmless preferences and security-relevant directives. Organisationally, the problem often surfaces only after a compromised branch, leaked token, or unexpected deployment, at which point project-local configuration becomes operationally unavoidable to examine and contain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers improper secret management and trust in repository-loaded settings. |
| NIST CSF 2.0 | PR.AC-4 | Maps to least-privilege access and control over tool-initiated actions. |
| OWASP Agentic AI Top 10 | Agentic tools can ingest repo instructions that alter tool authority and behavior. |
Restrict what repository-local configuration can change and require approval for privilege-affecting settings.
Related resources from NHI Mgmt Group
- Why are local .env files and config notes risky in Microsoft 365?
- How should security teams keep identity security from becoming a pure IT project?
- How should teams respond to a local Linux privilege escalation flaw in shared environments?
- Why do configuration checks miss identity risk in SaaS environments?
