Topic starter
18/08/2026 2:49 pm
TL;DR: AI-assisted development is moving risk into repository files and agent instructions, with Xygeni pointing to MCP configs and AI-suggested dependencies as the cause. Repository governance now has to reach beyond source review to inventory, provenance, and runtime policy enforcement.
Editorial analysis by NHI Mgmt Group, based on content published by Xygeni: “The AI Attack Surface Nobody Is Taking into Account”.
Key questions
Q: Why do AI control files create a new security risk?
A: AI control files matter because they can change agent behaviour without looking like executable code to a human reviewer.
Q: What breaks when repository review is the only control for AI-assisted development?
A: Review-only control breaks when the risky decision happens before a human sees the artefact.
Q: How should teams govern AI-suggested dependencies and package trust?
A: Teams should treat AI-suggested dependencies as untrusted until validated.
Practitioner guidance
- Govern AI control files as release artefacts Require review and policy checks for rules files, skills, hooks, and MCP configs before they can influence an agent in a repository.
- Validate AI-suggested dependencies before install Block package installation until registry presence, package metadata, and behavioural checks confirm the dependency is legitimate.
- Build an AI-BOM for every AI-enabled application Inventory models, datasets, providers, dependencies, and agent controls so delivery teams can see what is actually in scope.
Bottom line: AI-assisted development moves security risk into the files and instructions that govern agent behaviour, not just the source code itself.
Glossary terms: AI-BOM, Slopsquatting, MCP Configuration, Agent Control File
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
18/08/2026 3:31 pm
Repository trust has become an identity problem for AI-assisted development. The article describes a shift from human-selected code to AI-suggested instructions and packages, which means the authority to introduce risk now sits partly with the agent. That is an identity and governance issue because the organisation must decide what the assistant is allowed to propose, install, or execute. Practitioners should treat AI-assisted commits as governed actions, not passive content.
A question worth separating out:
Q: Should organisations prioritise AI-BOM work before runtime blocking?
A: They should do both, but AI-BOM comes first when the organisation cannot reliably inventory its AI footprint. Runtime blocking is essential for containment, yet inventory and provenance tell teams what they are actually governing, which is critical for release assurance and accountability.
👉 Read our full editorial: AI attack surface is moving into the repo and pipeline