Shadow AI in the SDLC is exposing blind spots in AppSec

At a glance

What this is: This is an analysis of Shadow AI in the software development lifecycle, showing that AI tools leave detectable signals across repositories, assistants, and MCP integrations.

Why it matters: It matters because AppSec and identity teams need visibility into AI-driven access, configuration, and code generation before those signals become unmanaged privilege and supply chain risk.

By the numbers:

• 97% of organisations lack visibility into how and where AI is being used across their software development lifecycle.

👉 Read Cycode's analysis of Shadow AI mapping across the SDLC

Context

Shadow AI in the SDLC is a governance problem before it is a tooling problem. When developers can add AI assistants, AI rule files, and MCP connections directly into repositories, existing AppSec and identity controls often miss the resulting configuration, privilege, and audit trail. The first challenge is knowing what AI is present, where it runs, and what it can reach.

That visibility gap matters because AI tools in development behave like a new class of non-human identity with transitive access into code, data, and external services. Once those capabilities are embedded in repos or CI/CD workflows, traditional self-reporting and periodic review are not enough. The same pattern appears across NHI programmes: if the access path is not inventoried, it is not governable.

Key questions

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. Repository content, comments, and file names must be treated as untrusted input because they can steer agent behaviour. The goal is to prevent context from becoming an indirect command channel.

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. An assistant that can read mail, use plugins, or access files can be steered into harmful action if its context is manipulated or its permissions are too broad. The security problem is the access path, not whether the system is self-aware.

Q: What breaks when MCP integrations are not governed tightly?

A: Tool trust breaks first, then command integrity, then secret exposure. If an assistant can register or trust the wrong MCP server, the environment may execute commands or disclose data in ways the developer never intended. That makes MCP onboarding part of access governance, not a simple configuration step.

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.

Technical breakdown

How AI rule files change code generation control

AI rule files are repository-level instructions that shape how an assistant generates or modifies code. They are typically committed as plain text, inherited by anyone using the repo, and executed implicitly without a separate approval workflow. That makes them different from conventional application configuration, because the file does not just set parameters, it alters the behaviour of the system producing code. The security issue is not only whether the rule content is safe, but whether the organisation knows which repositories contain rules, which assistant reads them, and whether those rules are stale, conflicting, or incomplete across languages and workloads.

Practical implication: treat AI rule files as governed policy artefacts and inventory them alongside other non-human access controls.

Why MCP servers create transitive access risk

MCP, or Model Context Protocol, connects AI assistants to external tools and services through authenticated integrations. In practice, an MCP server can let an assistant read repositories, query issue trackers, or interact with collaboration platforms using whatever scopes were granted at setup time. The architectural risk is transitive access: one configuration can extend an assistant's reach across multiple systems, often without the same visibility security teams expect from normal service accounts. Because MCP definitions can live in repos and IDE settings, the access boundary becomes portable, replicated, and difficult to review centrally.

Practical implication: map every MCP integration to its scopes, owning repo, and downstream systems before allowing it in production development flows.

What an AI bill of materials adds to SDLC governance

An AI Bill of Materials, or AIBOM, is an inventory of AI components, assistants, models, integrations, packages, and secrets used across development. Its value is not just documentation. It creates an evidence layer that helps security teams see where AI is operating, which tools are repeated across repositories, and where control coverage is missing. For AppSec and identity teams, the AIBOM becomes the bridge between code-level activity and governance decisions. It turns Shadow AI from an assumption into something that can be reviewed, approved, and audited across the lifecycle of software delivery.

Practical implication: use an AIBOM to connect repository evidence to approval, review, and exception handling processes.

NHI Mgmt Group analysis

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.

AI rule files create governance debt because they act as implicit policy without the controls usually attached to policy. A committed rule file can alter how code is generated across a repository, yet the article notes there is often no approval gate, no expiration mechanism, and no consistent enforcement model. That is a familiar pattern in NHI governance. Security teams lose control when instructions become durable, replicated, and invisible to standard review. The practitioner conclusion is to treat rule files as controlled policy objects, not convenience files.

Transitive access through MCP is the named concept teams need to confront. MCP does not just connect an assistant to a tool, it extends the assistant's operational reach into other systems through authenticated scopes. That widens the blast radius of any misconfiguration or compromised developer context. In NHI terms, this is delegated access without adequate lifecycle governance. The practitioner conclusion is to tie every MCP connection to scope review, ownership, and removal criteria.

AI inventory only becomes useful when it is tied to enforcement and auditability. The article's AIBOM framing is valuable because it moves detection toward governed inventory, but inventory alone does not reduce risk. AppSec and GRC teams still need policy, exception handling, and review workflows that can act on the findings. For identity programmes, the lesson is that visibility is the first control, not the last. The practitioner conclusion is to connect AI discovery to approval and audit processes before adoption scales further.

What this signals

Shadow AI will increasingly show up as an access governance issue inside the SDLC, not just as a code-quality concern. As assistants move deeper into repositories and pipelines, organisations will need a control model that ties discovery to ownership, review, and removal. The practical shift is from asking whether AI is present to asking whether its scope is bounded and auditable.

Transitive AI access: once assistants connect through MCP and repository-committed configuration, their permissions can spread beyond the original developer workflow. That means identity teams need to think in terms of delegated reach, not just named users. The most important programme question becomes whether each assistant can be explained, scoped, and revoked like any other privileged integration.

For identity and AppSec leaders, the near-term signal is that AI inventory work will merge with non-human identity governance. Resources such as the NHI Lifecycle Management Guide and OWASP Non-Human Identity Top 10 become relevant because the same lifecycle questions now apply to assistants, integrations, and machine-mediated privileges.

For practitioners

• 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. Put stale files on a removal or revalidation path before they continue shaping code generation.
• 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. Remove or restrict any integration whose permissions cannot be explained in business terms and approved through change control.
• 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. This is especially important where assistant usage is inconsistent across teams or repositories.
• Treat the AIBOM as an enforceable inventory Use the AI Bill of Materials to connect detected assistants, models, MCPs, packages, and secrets to explicit policy decisions. The inventory should feed audit, exception handling, and access review, not remain a reporting artifact.

Key takeaways

• Shadow AI in the SDLC is a governance failure when assistants, rule files, and MCPs operate outside inventory and review.
• The core risk is transitive access, where AI tooling can reach multiple systems through configuration that teams rarely track well.
• Practitioners should connect AI discovery to ownership, approval, and removal so visibility becomes enforceable control.

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• AI bill of materials: An inventory of the components used by an AI development environment, including models, plugins, hooks, skills, and agent integrations. It gives security teams visibility into what is operating in the stack so they can assess trust, dependency risk, and governance coverage.
• AI rules file: An AI rules file is a configuration artefact that tells a coding agent how to behave when generating or modifying code. Because it can influence future outputs, it should be governed as a sensitive control object, with provenance, review, and change management similar to other privileged automation inputs.

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

👉 The full Cycode post covers repository signals, MCP evidence chains, and AIBOM inventory details.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners translate identity controls into repeatable policy for modern non-human access patterns.