Shadow AI in the Enterprise: Q&A with Akto CEO Ankita Gupta on Enterprise Security Weekly

Shadow IT was a known problem. You could point a firewall at the edge, pull a list of web apps, and know what your employees were using. Shadow AI breaks that model. The assets are agents, MCP servers, and LLMs running behind the scenes on endpoints, in browsers, and inside IDEs, and most of them are invisible to security.

Akto co-founder and CEO Ankita Gupta joined Enterprise Security Weekly to walk through how the problem is changing and what security leaders should do about it. The conversation below has been edited for length and clarity.

Q: Shadow IT is a familiar concept. How do you define shadow AI, and how is it different?

Shadow AI is a new term, only 12 to 24 months old. It is different from shadow IT, but it is also part of it. AI has become one more class of technology that developers and employees pull into the organization.

When we define shadow AI, we mean any AI asset in use that did not exist before this wave: AI agents, MCP servers, LLMs, RAG databases. The most common ones we see inside organizations are AI agents and LLMs. That is where the risk concentrates, because these assets are shadow. They are invisible.

Q: AI is a technology, not just an app. With shadow IT, you could point a firewall at the edge and list every web app in use. With AI it might be an agent on a system, something web-based like ChatGPT, or AI baked into tools you already had, plus MCP. Do you have to approach discovery very differently now?

Completely different. In the traditional world, a firewall or cloud-edge discovery would surface web apps, and that covered most of shadow IT. Today the organization is dealing with MCP servers, agents, and LLMs. They are all models, all behind the scenes, not the web apps you used to catch.

So the visibility approach has to change. If employees are running LLMs, agents, or MCP servers, a lot of that activity lives on the desktop, not in the browser. People assume this is a browser problem because employees open ChatGPT in a tab. But the heavier usage is local: someone running a full agent, spinning up an MCP server, or working inside an IDE with Claude Code or GitHub Copilot. To discover all of it, you need visibility across three places: the browser, the IDE, and the local endpoint. You have to sit on the cloud, the endpoint, the browser, and the desktop to understand where AI assets actually live.

Q: A few years ago people shared documents through Dropbox, but nobody ran a dozen Dropbox alternatives. With LLMs, almost everyone has their own preferred tool. Does that proliferation make securing the content a different problem from finding it?

"Discovery is one problem. Securing it is a different ballgame."

The vulnerabilities are ones the traditional world has not seen: hallucination, prompt injection, context poisoning, memory poisoning. These terms did not exist a couple of years ago, so there is real learning involved in understanding the attacks that can happen against these assets.

And the scope is much larger. As agents take on work, the scope of tasks expands with them. What an employee does in a day now can be 10 to 100 times larger in scope than two or three years ago. They are not running two tasks a day, they are running fifty, because AI made each one faster. The attack surface expanded right along with it.

"You are not running two tasks a day. You are running fifty, and the attack surface expanded right along with it. It’s a new and much larger problem. "

Q: After discovery, companies face choices. Some pick one model for everyone; others impose no restrictions because they do not yet know what will be useful. In your experience, what do companies actually do as the next step?

It depends on the industry. In a highly regulated industry, you want to block sensitive actions as much as possible and only allow what falls inside your policies. In a less regulated industry, you might start with more experimentation and let employees use AI tools to their maximum advantage.

But the common pattern after visibility is the same: organizations start defining policies and guardrails on their AI assets. For an agent, the baseline is knowing the moment there is a prompt injection, a malicious skill, or a malicious MCP server. From there, you decide to block or alert. If it is a critical vulnerability like prompt injection, you may block it. If it is something like an information-disclosure issue, you may leave it in alert mode at first.

Early on, most organizations keep guardrail policies in violation-and-alert mode rather than blocking mode. As they get comfortable, they move toward blocking.

Q: Early on, the big fear was data leaking, like Samsung employees pasting code into ChatGPT, or the Meta executive whose email got deleted. Is leaking and handling sensitive data still the top concern with customers, or has it grown broader than that?

I would divide the problem into three categories.

The first is data exfiltration. Some teams call it AI DLP, but it is really exfiltration from any AI asset, whether an agent or an MCP server. That is still the number one challenge.

The second is access. How much access does this agent or LLM actually have, and can we define access-control policies around it? This is where agentic identity has become a critical risk topic.

The third is agent actions. You need visibility into what an agent does, and then control over it. This is not always access-related. Sometimes the agent simply takes the wrong action. You ask for one thing, and it deletes your email. Controlling agent actions is the third category we see organizations prioritize.

Q: A couple of years ago the risk was a person logging into ChatGPT with a proprietary question, human-scale and human-scoped. Now agents fire a continuous barrage at third-party models, grounded in your business context. Is the enterprise aware of how much that risk has grown in the last 24 months?

"The awareness of risk is there. The visibility is not."

They are very aware. Organizations are adopting AI fast, and they know their employees are using Claude Code, agents, and every kind of AI tool. They know it is no longer simple question-and-answer prompts. Employees are taking sophisticated actions, building websites and apps, and granting access to data in a fully automated, agentic way. Complete end-to-end work is being performed by the agent.

What they lack is visibility into who is doing what and where. Picture an organization with 50,000 employees. Anyone could be taking any action in AWS or on their endpoint. That lack of visibility is the biggest concern. The awareness of risk is there. The visibility is not.

Q: Now that AI has arms, legs, and a browser and can act on its own, are you or your customers running into big surprises, things they never anticipated employees using AI to do?

"Marketing, HR, finance, product managers. Everyone is a developer now."

A couple of big ones. I was at an Anthropic event recently, and we were discussing exactly this.

The first surprise is a new class of developer. It is not just the engineering team anymore. Marketing, HR, finance, product managers, everyone is a developer now. Everyone is using Cursor to build apps. The risk is no longer contained to development teams. The whole organization is building agents.

The second is the complexity of the actions. A non-developer in legal or HR, someone who never worked closely with tech, can now write a simple prompt and produce a genuinely complex application or agent, or automate their entire task. As a security leader, you are no longer dealing only with the cloud problem or the app problem that used to come from developers. The whole organization is executing complex tasks. The problem is complex at a much larger scale, and there is very little answer to it yet, even from the frontier model companies.

Q: Suddenly a finance expert is building complex things without knowing the ramifications. When your CFO and everyone else is effectively a developer shipping software, is that manageable? Can a security team keep up with all the new software?

"Developers became AI developers in the last 12 to 24 months, and they were never taught to secure what they build."

They have never done this before, and now they suddenly have the ability to build agents and applications and automate their work without relying on tech teams. It is a high-energy, experimental, exciting phase for them. They are focused on building and getting maximum advantage from AI. Securing it does not come to mind.

And to be honest, this is true even for developers. We have been discussing it in CISO sessions. Developers became AI developers in the last 12 to 24 months. They are building agents, but they were never taught to secure them. They are very smart teams building very capable agents, and the security of those agents is simply not what they are thinking about. Organizations will get there. There will be far more education, and employees will eventually understand what is safe and what is not. Today, most people cannot tell a malicious MCP server or a malicious skill from a legitimate one. That takes a fair amount of training.

Q: There is also a trust problem. When I did not know how to do something, my outgoing boss just said "Ask Claude." Now whole teams are learning the job by asking these tools, inheriting whatever bugs or bad advice come with it, and taking instructions from something that could have hallucinated or been compromised. How do you think about that?

AI is teaching AI now, and hallucination is real. There is heavy reliance on it. Even in cybersecurity, if I am writing a policy for an agent, I am probably using AI to write that policy. The manual effort across building and securing has become minimal, which can be risky.

But as an entrepreneur, I stay optimistic. In the long run, this gets better. AI becomes more deterministic in its actions and more capable of solving security problems. It has already improved a great deal over the last 12 to 24 months.

Q: Early on, companies ran an AI council, someone from security, someone from tech, always a lawyer. Is that still how it works, or are you seeing dedicated owners now, a VP of AI or a chief AI officer? Whose responsibility is this?

We used to see a lot of those councils. Now it is consolidating into a single function. Most often it sits under the CISO. Sometimes it lives in the CIO organization, or there is a dedicated AI team responsible for security and governance.

This is a good thing, because it means one team genuinely understands the security implications of AI and owns them. It is still early days for AI security, but it is reaching a point where things are becoming standardized and more mature. We will see a lot of that play out over the next six months.

Q: To wrap up: for someone who has not started at all, no idea what employees are doing, where the data is, or how much AI is in use, where do they begin?

"Visibility, then guardrails, then governance."

Start with visibility. Build a complete inventory of your AI assets. Know everything being used or hosted in your environment. That is the first phase, and it will take some time on its own.

Then move to guardrails. Begin with the basics: hygiene, sensitive-data exposure, prompt injection. From there you build toward a more complex guardrail framework. Visibility, then guardrails, then governance. That is the step one, two, three approach I would give anyone starting this journey.

This Q&A was adapted from Ankita Gupta's appearance on Enterprise Security Weekly. Watch or listen to the full conversation for the complete discussion on shadow AI, agentic identity, and securing AI adoption across the enterprise.