Topic starter
18/08/2026 2:49 pm
TL;DR: AI-assisted development is shifting the attack surface into repository files, model instructions, MCP configs, and AI-suggested dependencies, according to Xygeni, while public incidents such as s1ngularity, Shai-Hulud, and slopsquatting show how quickly malicious code can enter before review. Traditional AppSec controls do not fully cover agent behaviour or configuration-layer risk, so governance now has to extend to AI-BOM, provenance, and runtime 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: How should teams govern AI-suggested dependencies and package trust?
A: Teams should treat AI-suggested dependencies as untrusted until validated.
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.
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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
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