Ownership should sit with the teams that govern software supply chain and identity of development tooling, not only with developers using the tools. Rules files and extensions can act like privileged non-human identities because they influence future actions. That makes approval, revocation, and periodic review a shared security responsibility.
Why This Matters for Security Teams
AI rules files and developer extensions are not harmless productivity add-ons. They can change how code is generated, what tools an assistant can invoke, and which secrets or repositories are exposed during development. That makes them part of the software supply chain and identity perimeter, not just a developer preference issue. Current guidance suggests treating them with the same scrutiny as other privileged non-human identities, especially when they can persist, auto-update, or inherit broad access.
The risk is visible in incidents like the DeepSeek breach, where exposed credentials and sensitive records showed how quickly AI-adjacent systems can become an access problem. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful here because extension governance maps directly to control ownership, access restriction, and change management.
In practice, many security teams encounter risky extensions only after a compromise, not through deliberate review of the rules that shaped the compromise.
How It Works in Practice
Ownership should sit with the teams that can evaluate both code trust and identity trust: application security, platform security, developer experience, and supply chain governance. Developers should still be able to request and use tools, but they should not be the only approvers for extensions that can inject prompts, rewrite commands, read workspace files, or call external services. A rules file can behave like an instruction set for an autonomous assistant, so its approval path should reflect that operational power.
Practically, organisations should define an approval model that covers origin, signature or publisher trust, requested scopes, data access, update mechanism, and revocation path. Use a catalogue of approved extensions, require change review for new rules files, and tie each approved item to an owner who can remove it when risk changes. This is consistent with the spirit of NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where organizations need accountable change control and least privilege.
- Review extensions as software artifacts, not just user preferences.
- Limit permissions to the minimum workspace, repository, and network scope.
- Track who approved a rules file, when it was last reviewed, and what it can influence.
- Revoke immediately when a tool’s behavior, publisher, or trust model changes.
Security teams should also watch for AI systems learning unsafe patterns from local codebases, a concern reflected in the State of Secrets in AppSec. These controls tend to break down in fast-moving developer environments with self-serve extension installs and unmanaged update channels because the approval process cannot keep pace with tool drift.
Common Variations and Edge Cases
Tighter control often increases developer friction, requiring organisations to balance speed against trust and revocation discipline. That tradeoff is real, especially in teams that rely on rapid experimentation or internal extension marketplaces. Guidance is still evolving on how much autonomy to grant low-risk tools, so there is no universal standard for this yet. The safest pattern is to classify extensions by blast radius rather than by team preference.
Some edge cases deserve special handling. A rules file stored in source control may need code-owner approval, while a marketplace extension with broad file or network access may need security sign-off and periodic revalidation. Extensions that can call LLM endpoints, access secrets, or modify CI pipelines should be treated as privileged software components. The Google Firebase misconfiguration breach is a reminder that misconfiguration and exposed trust boundaries can turn a normal service into a high-impact access path.
For mature programs, ownership is shared but not diffuse: platform teams maintain the allowlist, security defines control requirements, and engineering managers enforce local compliance. That division keeps accountability clear without making every developer a security reviewer.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and 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-04 | Covers governance for privileged non-human identities, which fits rules files and extensions. |
| OWASP Agentic AI Top 10 | A-03 | Applies because extensions can steer agent behavior and tool use at runtime. |
| CSA MAESTRO | GOV-03 | Governance and ownership are central for AI toolchains and autonomous extensions. |
| NIST AI RMF | GOVERN | Ownership, accountability, and oversight are core AI RMF governance concerns. |
| NIST CSF 2.0 | PR.AC-4 | Access control and least privilege apply to extension scopes and update rights. |
Treat AI rules files and extensions as governed NHI assets with approval, review, and revocation controls.
