Shadow AI discovery is failing across endpoints, browsers and IDEs

At a glance

What this is: This is a Q&A on shadow AI and its key finding is that discovery and control now require visibility across the browser, IDE and local endpoint, not just the network edge.

Why it matters: It matters because IAM, NHI and security teams need to govern AI agents and MCP servers as identity-bearing assets before invisible usage turns into unmanaged access and data exposure.

👉 Read Akto's Q&A on shadow AI discovery, guardrails and governance

Context

Shadow AI is an identity governance problem before it is a tooling problem. When agents, MCP servers and LLMs run on endpoints, inside IDEs and behind browser sessions, the old assumption that discovery starts and ends with web-app visibility no longer holds. For identity security teams, that means the control question shifts from "what app is this?" to "what identity is this AI asset using, and who can it act for?"

The article frames three operational realities: discovery is fragmented, security is broader than discovery, and the attack surface expands as employees use AI to complete more work faster. That combination pushes shadow AI into the same governance territory as other unmanaged non-human identities, except with a faster change rate and more distributed execution points. Akto's interview positions the problem as an enterprise-wide visibility gap, not a niche developer issue.

Key questions

Q: How should security teams discover shadow AI agents in the enterprise?

A: Use endpoint artefacts first. Look for agent directories, service definitions, local ports, and process names that prove the software is installed and active. Network traffic alone is too ambiguous because legitimate browser and API activity can look identical to agent behaviour. Discovery should produce an inventory of where the agent runs, what it can reach, and whether it is sanctioned.

Q: Why do shadow AI tools complicate IAM governance?

A: Shadow AI tools complicate IAM because they can hold real privileges without appearing in normal inventory or review processes. If a tool can send data, call APIs, or reach databases, it behaves like an identity with access. Governance fails when the access path exists but no one can name or own it.

Q: What do teams get wrong about AI guardrails and identity controls?

A: They often assume a content filter is a substitute for access governance. It is not. Guardrails reduce unsafe responses after the session has started, but they do nothing to limit who can reach the system, what data sources the agent can query, or whether delegation is over-broad.

Q: Who should own shadow AI risk in an organisation?

A: Shadow AI risk should be owned jointly by IAM, security operations, privacy, and compliance teams because the issue spans identity, data handling, and regulatory exposure. If ownership sits in only one function, the organisation usually gets either weak enforcement or weak accountability, but not both.

Technical breakdown

Why shadow AI escapes browser-only discovery

Shadow AI is not confined to a browser tab. The article describes AI assets running in the browser, the IDE and on the local endpoint, which means a firewall or web proxy sees only part of the picture. That matters because MCP servers, agents and local copilots can initiate actions and access data without presenting as a traditional web app. Discovery therefore becomes an endpoint and workspace telemetry problem, not just a network monitoring problem. Security teams need to treat these assets as distributed runtime identities with multiple execution surfaces.

Practical implication: build discovery across endpoint, browser and IDE telemetry instead of relying on edge visibility alone.

How agentic access changes the identity model

The article separates three risk classes: data exfiltration, access and agent actions. That is a useful distinction because an AI system can be dangerous even when it does not leak data, simply by taking the wrong action with valid access. In identity terms, the control problem is not only authentication. It is also entitlement scope, action authorisation and the ability to observe what the agent actually does during a session. Once AI assets can perform more work in less time, the identity boundary becomes behavioural, not just credential-based.

Practical implication: govern AI assets by access scope and permitted action classes, not by login controls alone.

Why guardrails have to follow visibility

Akto's interview describes a sequence: visibility first, then guardrails, then governance. That ordering is technically sound because you cannot enforce policies on AI assets you have not found. Guardrails in this context include blocking prompt injection, flagging malicious skills and controlling sensitive actions through alerting or blocking modes. The deeper point is that AI governance fails when organisations try to start with policy without a complete inventory of assets, prompts, connectors and execution paths. The architecture has to reflect how AI work is actually composed across tools and endpoints.

Practical implication: inventory AI assets and their connectors before turning policy into blocking or alerting rules.

Threat narrative

Attacker objective: The objective is to exploit unmanaged AI assets to access sensitive context, trigger unsafe actions or move data out of governance boundaries.

1. Entry begins when employees or developers introduce shadow AI through local tools, browser-based AI services, IDE copilots or MCP servers that are not centrally approved or inventoried.
2. Escalation occurs when those AI assets gain access to code, business context or connected systems and then perform actions beyond what the organisation can observe or certify.
3. Impact follows when the agent leaks sensitive data, executes the wrong action or expands the attack surface across many faster, AI-assisted workflows.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow AI is now an identity discovery problem, not just an application discovery problem. The article makes clear that AI assets live on the endpoint, in the IDE and behind browser sessions, which breaks the assumption that network-edge discovery is enough. That shifts the field toward continuous inventory of non-human identities across local and cloud execution points. Practitioners should stop treating AI visibility as a point-in-time scan and start treating it as a persistent governance requirement.

Agentic AI expands the blast radius of ordinary employee behaviour. When non-developers can build agents and automate work without central oversight, access growth is no longer limited to engineering teams. That is a governance shift, because the number of actors creating AI-mediated access paths multiplies while review capacity stays static. The result is a broader identity surface with weaker accountability, and security teams should assume AI creation is becoming a business-user activity, not a specialist one.

Visibility, then guardrails, then governance is the right order because unobserved AI cannot be governed. The article's operational sequence is correct in identity terms: first find the assets, then define what they may do, then formalise ownership and policy. That sequence matters because prompt injection, malicious skills and hidden MCP servers are enforcement problems only after discovery exists. Practitioners should design governance around observable AI behaviour, not around policy intent alone.

Agentic identity is emerging as a distinct control plane inside enterprise IAM. Akto's framing around access, actions and data exfiltration shows that AI systems need their own entitlement and monitoring logic. This is not a duplicate of human IAM, because the subject can initiate work continuously and at machine speed. The implication for the market is that identity programmes will increasingly need separate controls for human users, workloads and AI agents.

Shadow AI creates credential and connector risk even when the model itself is not compromised. The article points to MCP servers and local agents that connect to business systems and codebases, which means the dangerous object is often the integration path, not the model prompt. That shifts governance toward connector review, scoped permissions and runtime monitoring of what the AI can reach. Practitioners should treat every AI integration as a potential non-human identity with privileged adjacency.

What this signals

Shadow AI pushes identity programmes toward continuous discovery of AI assets and connectors, because review cycles built for static accounts will not keep pace with endpoint-level adoption. The important programme shift is to treat every local agent or MCP server as an identity-bearing workload that needs ownership, scope and visibility from the start.

The operational question is no longer whether employees use AI, but whether the organisation can see which AI assets can reach code, data and production systems. That is where governance will fail first if teams keep relying on browser-centric controls or isolated app inventories.

For practitioners

• Build a complete AI asset inventory Map AI agents, MCP servers, LLM use and local copilots across the browser, IDE and endpoint so you know where shadow AI actually lives. Include business-owner, data-access and execution-context fields so each asset has an accountable identity record.
• Classify AI access by action, not just login Separate read, write, publish and delete capabilities for each AI asset and tie them to the systems they can reach. This makes it easier to spot when an agent has more authority than its task justifies.
• Introduce guardrails before broad enablement Start with alerting for prompt injection, malicious skills and sensitive-data exposure, then move to blocking where the business use case is clear. Use policy exceptions sparingly and require review for every connector that extends AI reach.
• Assign ownership for every AI-mediated workflow Make one team accountable for each AI workflow from intake to runtime behaviour, including the prompts, data sources and downstream actions. Without an owner, shadow AI becomes a shared blind spot rather than a governable service.

Key takeaways

• Shadow AI is an identity visibility problem because the most relevant assets are often running on endpoints, in IDEs and inside delegated integrations.
• The control gap is not only data leakage, but also unmanaged access and unreviewed agent actions that expand the attack surface.
• Security teams need asset inventory, action-level guardrails and explicit ownership before shadow AI becomes routine enterprise infrastructure.

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.
• Agentic Identity: An agentic identity is a non-human identity used by an autonomous system that can act, call tools, and access data with execution authority. It needs the same governance discipline as other privileged identities, plus runtime context, ownership mapping, and revocation paths.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.

What's in the full article

Akto's full Q&A covers the operational detail this post intentionally leaves for the source:

• Direct guidance on how enterprises are distinguishing discovery from enforcement across shadow AI assets
• The interview's practical examples of prompt injection, malicious skills and malicious MCP servers in real workflows
• How organisations are deciding whether to alert or block specific AI behaviours as they mature their controls
• The discussion of how ownership is consolidating under the CISO, CIO or dedicated AI governance teams

👉 Akto's full interview covers the visibility gap, AI action control and the move from alerting to blocking.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.