Notifications
Clear all
Topic starter
02/08/2026 12:07 pm
TL;DR: Shadow AI now spans IDEs, browsers, SaaS apps, AI agents, and MCP connections, creating visibility gaps, data leakage, and autonomous actions that traditional IT controls were not built to manage, according to Akto. The control problem is no longer whether AI is present, but whether enterprises can govern what it can see, decide, and do.
NHIMG editorial — based on content published by Akto: What is Shadow AI? Learn what Shadow AI is, how it differs from Shadow IT, key enterprise risks, real-world examples, and how to govern AI usage safely with visibility and control
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: What breaks when organisations ban shadow AI instead of governing it?
A: Bans often push AI use into personal accounts, unmanaged devices, and hidden workflows, which removes visibility from security and makes data exposure harder to detect.
Q: Why do conversational AI systems create new identity and access risks?
A: Because they can combine data retrieval, decision-making, and execution in a single interaction.
Q: How do you know if shadow AI governance is actually working?
A: You know it is working when you can see where AI is used, what data it touches, what actions it can take, and whether those actions are blocked or approved in real time.
Practitioner guidance
- Discover shadow AI across workflows Inventory AI usage in IDEs, browsers, extensions, SaaS apps, and MCP-connected tools before policy work starts.
- Classify AI tools by action risk Separate read-only assistants from tools that can call APIs, modify records, or trigger business processes.
- Bind permissions to agent scope Treat agent access like NHI access and define narrow scopes, explicit lifetimes, and revocation points for every AI system that touches enterprise data.
What's in the full article
Akto's full article covers the operational detail this post intentionally leaves for the source:
- Examples of shadow AI in IDEs, browsers, SaaS apps, and MCP-connected workflows
- Step-by-step guidance for discovering AI usage across employee tools and business processes
- Runtime guardrail concepts for prompts, data access, and AI-driven actions
- Policy-building detail for approved AI use, human review, and safe enablement
👉 Read Akto's article on what shadow AI is and how to govern it →
Shadow AI governance gaps: what security teams need to control now?
Explore further
02/08/2026 1:12 pm
Shadow AI governance debt is now a board-level issue: enterprises are accumulating unmanaged AI usage faster than they can define policy, visibility, and accountability. Because AI is embedded in browsers, IDEs, and SaaS workflows, security teams are losing control at the moment of adoption rather than at the moment of breach. The practical conclusion is that AI governance can no longer be treated as an innovation side project.
A question worth separating out:
Q: Who is accountable when rogue AI accesses regulated data or enterprise systems?
A: Accountability should sit with the teams that approve the use case, grant the permissions, and own the data or application being accessed. Security can set the control model, but legal, compliance, IT, and business owners all need defined decision rights and revocation authority.
👉 Read our full editorial: Shadow AI is a governance problem, not just an IT sprawl issue
