Notifications
Clear all
Topic starter
20/08/2026 5:36 pm
TL;DR: 97% of organisations lack visibility into how AI is used across the SDLC, while developers are embedding rule files, skills, MCP servers, and AI assistants directly into repositories and pipelines, according to Cycode. The governance problem is no longer tool sprawl alone, but unmanaged AI activity that behaves like a new layer of non-human identity and access.
NHIMG editorial — based on content published by Cycode: You Can’t Secure What You Can’t See, How Cycode Maps Every AI Tool in Your SDLC
By the numbers:
- 97% of organisations lack visibility into how and where AI is being used across their software development lifecycle.
Questions worth separating out
Q: How should security teams control agentic AI tools in untrusted repositories?
A: Security teams should run agentic tools in isolated environments with no production secrets, restricted filesystem scope, and tightly controlled network access.
Q: Why do AI assistants create access risk even when they are not AGI?
A: Because the risk comes from delegated authority, not human-like intelligence.
Q: What breaks when MCP integrations are not governed tightly?
A: Tool trust breaks first, then command integrity, then secret exposure.
Practitioner guidance
- Inventory AI rule files across every repository Scan for repository-committed AI rule files such as assistant instructions, then classify which assistants they govern, whether they are reviewed, and whether they are still in use.
- Map every MCP server to its granted scopes Build a register of all MCP integrations, including the connected service, credential scope, repository location, and developer or team owner.
- Extend SDLC review to AI-assisted commits Detect AI-assisted code contributions through commit metadata, bot users, and workflow hooks, then add review checkpoints for code that was generated or modified by assistants.
What's in the full article
Cycode's full analysis covers the operational detail this post intentionally leaves for the source:
- Repository-level detection logic for AI rule files, skill files, and assistant hooks across source control
- The evidence chain Cycode uses to trace MCP servers back to repositories, developers, and connected services
- AIBOM inventory categories and how the platform surfaces AI components for review and audit
- Examples of repository and workflow signals that indicate AI assistants are contributing to code or automation
👉 Read Cycode's analysis of Shadow AI mapping across the SDLC →
Shadow AI in code repos: what AppSec teams are missing?
Explore further
20/08/2026 6:22 pm
Shadow AI is becoming an identity governance problem, not just an AppSec visibility gap. The article shows developers embedding assistants, MCP servers, and rule files directly into repositories and CI/CD workflows. That creates machine-mediated access paths that behave like non-human identities with delegated capability. If teams cannot inventory those identities, they cannot govern their scope, lifecycle, or review cadence. The practitioner conclusion is simple: AI activity in the SDLC now belongs in the identity and access control conversation.
A question worth separating out:
Q: How do teams know whether AI governance is actually working?
A: Look for evidence that every AI interaction can be traced end to end, from identity and intent to output and enforcement. If auditors can ask for a transaction and receive a complete record in hours, not weeks, the programme is producing usable control evidence rather than just documentation.
👉 Read our full editorial: Shadow AI in the SDLC is exposing blind spots in AppSec
