Notifications
Clear all
Topic starter
09/06/2026 11:14 pm
TL;DR: AI security now has to start in the repository because teams often cannot see where AI is used, what agents are active, or which permissions and MCP connections they hold, according to Lasso Security. That matters because static AppSec controls miss AI-native risks such as prompt injection sinks, unsafe tool execution, and shadow AI before deployment.
NHIMG editorial — what this means for NHI practitioners
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map AI primitives in source control Scan repositories for models, agent code, frameworks, tools, and MCP server references before they reach production.
- 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.
- 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.
What's in the full announcement
Lasso Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Repository integration steps for the GitHub App and the access model behind selective repo scanning
- Examples of the security graph output and how the vendor visualises models, agents, tools, and services
- The article's own breakdown of AI-native risk categories such as prompt injection, shadow AI, and MCP proliferation
- The vendor's discussion of ephemeral scanning and the planned on-premise metadata-only model
👉 Read Lasso Security's analysis of GitHub-based AI security visibility →
GitHub AI visibility: what it means for IAM and security teams?
Explore further
10/06/2026 1:30 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: GitHub-based AI security visibility is the new shift-left control
