GitHub-based AI security visibility is the new shift-left control

At a glance

What this is: This is a shift-left analysis of GitHub-based AI security visibility, with the core finding that repository-level discovery is needed to expose hidden AI components, permissions, and risk relationships before deployment.

Why it matters: It matters because IAM, NHI, and security teams cannot govern what they cannot inventory, and AI systems introduce new identity, tool, and access paths that legacy AppSec views do not capture.

👉 Read Lasso Security's analysis of GitHub-based AI security visibility

Context

AI security left means finding AI components as early as possible in the software delivery path, ideally in source control before deployment. The problem is not just code quality, but identity and access visibility: teams often do not know where AI is embedded, which agents are live, or what they can reach.

That creates a governance gap across NHI, agentic AI, and development workflows. Repository-level analysis can expose models, agents, tools, and MCP servers before they become runtime dependencies, which is why the security question is shifting from detection in production to inventory at build time.

The article reflects a typical starting point for modern AI programmes: broad adoption, weak inventory discipline, and fragmented understanding of tool-connected access.

Key questions

Q: How should security teams discover AI usage in source code before deployment?

A: They should scan repositories for model calls, agent workflows, tool integrations, and MCP references, then tie each finding to an owner and a reachable system. Discovery is only useful when it becomes an inventory of who can act on what and where the trust boundaries sit. That is the point where repository scanning becomes governance.

Q: Why do flat AI asset inventories miss the real security risk?

A: Because the risk usually sits in the connection between components, not in the component name itself. A model with limited purpose is very different from the same model connected to a sensitive API, production database, or external tool chain. Relationship-aware analysis is what exposes blast radius and privilege expansion.

Q: What should teams do when MCP servers are proliferating across projects?

A: They should classify MCP servers as governed access paths, assign ownership, and review the systems each server can reach. Untracked connectors often become shadow AI infrastructure, which means security and IAM teams need an approval and inventory model before those paths multiply further.

Q: How do organisations reduce prompt injection risk in AI workflows?

A: They should map every point where untrusted content can reach a model or agent that has tool permissions. If the model can translate external text into internal action, the boundary is already too porous. The control objective is to prevent untrusted inputs from becoming executable intent.

How it works in practice

Why repository-level AI discovery matters

Traditional AppSec scans are built for libraries, code defects, and known dependency issues. AI-enabled code introduces model calls, agent logic, tool chains, and external connectors that are not visible through static dependency checking alone. Repository analysis can identify these primitives before deployment, which is the first step in governing where prompts go, what systems are reachable, and which workflows have expanded trust boundaries. The key technical shift is from scanning artefacts to mapping execution relationships.

Practical implication: build repository scans that explicitly detect AI primitives, tool links, and external service connections.

Security graphs expose AI trust relationships

A security graph links models, agents, tools, and data sources into one view of how an AI application is assembled. That matters because the risk is often in the relationship, not the component itself. A benign model becomes risky when it can call a sensitive API, inherit broad repository permissions, or pass prompts into untrusted content. Graph-based analysis helps explain blast radius, because it shows how one compromised input or overbroad connector can cascade across the environment.

Practical implication: require relationship mapping, not just asset lists, when reviewing AI application risk.

MCP servers and prompt injection create new access paths

Model Context Protocol servers are connective tissue between models and enterprise systems, which makes them powerful and risky. If an AI workflow can ingest untrusted content, a prompt injection sink can alter model behavior or trigger unwanted tool actions. If MCP growth is unmanaged, the environment accumulates hidden pathways into data stores and SaaS tools. These are not ordinary app vulnerabilities. They are identity-adjacent execution paths that can turn context into action without the same controls used for human-driven workflows.

Practical implication: treat MCP connections and prompt ingress points as governed access surfaces, not just integration details.

NHI Mgmt Group analysis

Repository-first AI governance is becoming the new control plane. Security teams cannot rely on production monitoring alone when AI components are assembled in code before they are deployed. The governance problem starts in the repository because that is where hidden agents, tools, and model links first become durable. Practitioners should treat source control as the earliest enforceable identity and access boundary for AI systems.

Graph-based visibility is a more accurate risk model than flat inventories. A list of models or agents does not explain how trust expands across connected services, data stores, and external APIs. The security graph is the useful unit because it reveals potential blast radius and shows where privilege becomes compounded through relationships. This is a field-level shift from component counting to dependency-aware governance.

MCP proliferation is creating shadow access paths that look like integration work but behave like identity sprawl. The issue is not simply that more servers exist. It is that each unmanaged connector can extend tool reach, data exposure, and execution scope in ways that security review teams may not see early enough. That makes MCP governance a non-human identity discipline as much as an application security one. Practitioners need to classify those connectors as governed access paths, not convenience plumbing.

Prompt injection sinks are a trust-boundary failure, not just an AI content problem. When untrusted input reaches a model or agent with tool permissions, the control gap is the absence of a boundary between external text and internal action. That failure spans human security review, NHI permissions, and agentic execution logic in one chain. The implication is that AI governance must be designed around where action can be induced, not only where code can be exploited.

Continuous AI security will replace one-time review as the operating model. AI systems evolve through prompts, model updates, new connectors, and agent workflows that do not fit static release assumptions. That means identity and security governance must track change at build time and runtime together. Practitioners should assume the AI attack surface is dynamic and manage it as a living control environment.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, which shows that identity exposure often becomes recurring rather than isolated.
• For a broader baseline on hidden access risk, see Ultimate Guide to NHIs , Key Challenges and Risks for the visibility and sprawl patterns that make AI governance harder.

What this signals

Shadow AI will increasingly look like identity sprawl before it looks like application sprawl. Once AI features are embedded directly in repositories, the governance problem shifts from model selection to access control, ownership, and lifecycle oversight. With more than 1 in 5 non-human identities already believed to be insufficiently secured according to The 2024 ESG Report: Managing Non-Human Identities, teams should expect AI inventory gaps to widen unless code-to-access mapping becomes routine.

Repository-based discovery also changes how security programmes measure maturity. A team that can name its models but not its agents, tools, and connected services still lacks the control picture needed for risk-based prioritisation. That is why AI security needs to be folded into change management, not left as a separate review lane.

For practitioners

• Map AI primitives in source control Scan repositories for models, agent code, frameworks, tools, and MCP server references before they reach production. The goal is to create a verified inventory of AI assets tied to the codebase, not a separate spreadsheet of suspected usage.
• Require relationship-based risk review Review how models connect to data stores, APIs, and internal services, then classify the likely blast radius of each path. Focus on connected services rather than isolated components, because the biggest exposure usually appears in the dependency chain.
• Treat MCP connectors as governed access Place Model Context Protocol servers under the same review discipline used for sensitive integrations, including ownership, scope, and approval. The practical objective is to eliminate unmanaged pathways into internal systems that no one has formally accepted.
• Add prompt ingress checks to CI/CD Validate where untrusted content can reach model or agent decision points before code merges. If a prompt can influence tool execution or data access, that path needs the same scrutiny as any privileged automation route.

Key takeaways

• AI security left is really an identity visibility problem, because teams cannot govern agents, tools, and permissions they cannot inventory.
• Graph-based mapping is more useful than static asset lists because the risk emerges from connected data flows and trust relationships.
• Security programmes should move AI controls into source control and CI/CD now, before hidden integrations become persistent exposure paths.

Key terms

• Security Graph: A security graph is a relationship map that shows how AI components connect to each other and to surrounding systems. In this context, it is more useful than a flat inventory because it reveals trust paths, data flows, and the likely blast radius of a model, agent, or tool integration.
• Shadow AI: Shadow AI is AI usage that exists inside the organisation without clear approval, ownership, or visibility. It becomes a governance problem when experimental branches, internal copilots, or agentic workflows create access paths that security teams cannot inventory or review in time.
• MCP Server: An MCP server is a connection layer that lets AI systems interact with tools and data sources through the Model Context Protocol. In governance terms, it behaves like an access pathway, because it can extend what an AI model can reach and influence across enterprise systems.
• Prompt Injection Sink: A prompt injection sink is any point where untrusted content reaches a model or agent and can alter its decisions or tool actions. The risk is not the text itself, but the fact that external input can become internal execution when boundaries are not enforced.

Deepen your knowledge

Repository-level AI discovery, graph-based visibility, and prompt-injection governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a control model for AI systems from source code outward, it is worth exploring.

This post draws on content published by Lasso Security: Shift AI Security Left, introducing Lasso’s GitHub integration. Read the original.