Notifications
Clear all
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.
NHIMG editorial — based on content published by Xygeni: AI attack surface in application security and AI-assisted development
By the numbers:
- Research this year reviewed 4,000 of these skills: 36% had at least one security flaw.
- 79% have no visibility into the AI agents and MCP systems running in their own environment.
- 43% can’t audit or inventory the AI tools they’re already using.
Questions worth separating out
Q: How should security teams implement AI code generation controls in the SDLC?
A: Start at the point of generation, not at the point of release.
Q: Why do AI-suggested dependencies create supply chain risk?
A: AI-suggested dependencies create risk because the model can invent package names that appear plausible but are not trustworthy.
Q: What breaks when skills, rules files, or MCP configs are not reviewed like privileged controls?
A: What breaks is the assumption that these files are harmless text.
Practitioner guidance
- Inventory AI-assisted build inputs Classify models, agents, skills, rules files, MCP configs, and AI-suggested dependencies as governed software inputs, then require ownership and approval for each class.
- Block unverified package installs Require registry verification, package intent analysis, and provenance checks before any AI-suggested dependency can enter CI or a local environment.
- Apply least privilege to agent tool access Restrict what an AI agent can read, write, install, or invoke so that a compromised assistant cannot turn a single suggestion into broad execution rights.
What's in the full article
Xygeni's full analysis covers the operational detail this post intentionally leaves for the source:
- Walkthroughs of how the AI attack surface appears in skills, MCP configs, and dependency workflows.
- The live demo path showing how policy enforcement blocked a malicious package across multiple install methods.
- Details on the AI-BOM and the evidence needed to support audit and compliance workflows.
- Implementation timing and deployment scope for teams rolling out agent-side controls.
👉 Read Xygeni's analysis of the AI attack surface in application security →
AI attack surface in repositories: what IAM teams need to know?
Explore further
18/08/2026 3:31 pm
AI-assisted development has become an identity and trust problem, not just an AppSec problem. When an agent can choose packages, write config files, or call tools, it is acting as a non-human identity that needs governed authority. The control question shifts from whether the code is clean to whether the entity making the decision was allowed to make it. Practitioners should treat AI-generated actions as governed identity events, not passive tooling output.
A few things that frame the scale:
- 79% have no visibility into the AI agents and MCP systems running in their own environment, according to The State of Secrets in AppSec.
- 43% can’t audit or inventory the AI tools they’re already using, which leaves assurance teams without a reliable software boundary.
A question worth separating out:
Q: Who is accountable when an AI agent or build pipeline introduces malicious code?
A: Accountability sits with the teams that granted the agent, service account, or CI/CD pipeline its authority and failed to govern its lifecycle. That means IAM, platform engineering, security, and application owners all need clear control ownership for install rights, token revocation, and runtime containment.
👉 Read our full editorial: AI attack surface is moving into the repo and pipeline
