Hello folks. Today I would like to chat with you about some new challenges with AI usage control. My name is Viswesh Ananthakrishnan, VP of Product at Aurascape.

If you think back to when ChatGPT was first released and CISOs were grappling with how to manage the use of ChatGPT, we found responses across the spectrum. Some people said they would simply block these new AI apps and only allow a small set of restricted apps to be used.

We have come a long way since then. Today, CISOs at modern, progressive enterprises think about empowering their users with all these modern AI apps to increase their productivity, and they don’t really think about blocking large sets of apps as a viable strategy anymore. So in this climate, how should we think about securing the usage of apps?

The first point I would like to make is about what an app is. If you look at security products that have been shipping for many years now, which were not AI-specific, they had this concept of an app ID. And of course, there was also a watered-down notion of URL filtering: not quite an app, but still an effective way to manage and control the assets that people accessed over the internet. In terms of accessing apps in general, the idea was that this app ID would encapsulate all types of access to that app. In reality, that was far from true.

Most products would simply keep track of the home page of a particular app, and then also specific types of SaaS action control URLs, like uploading a file or downloading a file. So, very, very limited. The first problem in really understanding what an AI app is: you have to go much beyond that, to what I would call full traffic capture.

What I mean by that is, when you’re thinking about an AI app, you have to think about all the different ways a person might access that app: across different API endpoints, across different CDNs, app subdomains, different types of entitlements, different types of risks associated with those entitlements, and so on. What you really need is the ability to capture the full list of all possible FQDNs that map to that app, versus just the home page and a few SaaS action URLs. That’s the first step.

The second step is, if you really want full visibility into all these apps, you need to build a really large catalog, so that you can be truly selective about what you allow, what you warn about, what you confirm access to, and so on. When a product supports maybe a few hundred or a few thousand apps, that’s not enough anymore. You really need to support tens of thousands of AI apps, already built into a catalog that comes straight from the factory inside your product. So what that maps to is full traffic capture for a large scale of AI apps, in the tens of thousands.

Now, how do you get to know about these AI apps that are in the wild? The second point is really about fast discovery. In the age of agentic AI, it is now fully expected and possible for AI agents to do this task: visiting all those popular locations where these new AI apps are launched, where people go to find these new AI apps, and automatically start interacting with these apps, capturing all those interactions to build the signatures, to build the decoders to access these AI apps.

So the next part is about visiting all these popular locations where these apps are found, and then implementing a really fast agentic process to discover, decode, and start supporting these apps in the catalog, so that the time between when an app is first launched and when it’s available in a catalog to apply policy is a matter of hours, not days or weeks, as it used to be and still is with many vendors and their products today. That is the second big requirement and challenge, and how to overcome it today with the speed at which AI apps are being launched.

The next big challenge with AI apps is that it is not enough to just think about these apps as SaaS-delivered capabilities, because local AI discovery is now very important. And why is that?

Because when you think about agents that are running on your device, when people are running tools like Claude Code or Cursor, there is a lot of interaction with their local device’s file system, processes running on their devices, and so on. There are even cases where an entire LLM could be running on a server like Ollama somewhere down the hallway, where there is no access over the internet.

So this full visibility into what’s happening on your device, all the way from understanding the processes and their hierarchy, all the changes happening to the file system, all those commands coming back from the LLM, those bash commands that are affecting your file system in sometimes not so secure ways: all of that has to now be made visible and taken action on as part of your protection policies. So the next big stage, or challenge, with full AI usage control is understanding what’s happening locally on your device.

And so you need local AI discovery: an ability to apply policy at a process level and at a file system level.

Now, if you do all this, you still find a lot of cases where a customer might come to you and say, “Hey, you know what? I have this subscription for this very popular and useful AI app, and I would like you to develop a signature for it. I would like you to decode it so that I can then look at the prompts and responses in clear text.”

The challenge is that some of these subscriptions are expensive, and a product vendor may not have access to all of these paid subscriptions for AI apps. In that case, how do you support app IDs and decoders?

So one big challenge is how a vendor, a security product vendor, enables their customer to help themselves. What you really want is for your end customer to be able to capture the traffic on their own, develop the signature on their own, all with two clicks of a button, without having to deal with all that complexity, and then be presented with the option to treat that new app in the product just as if it came from the factory, all in a matter of a few hours. This is what I call custom app discovery.

So custom app discovery for AI apps, custom apps, is the next big challenge. In the past, people would perhaps capture packets and take many weeks to analyze them as human beings. But again, this is ripe for innovation. This is an area where you can use agents to automatically process all of this traffic. All you tell the user is, “Please go play with this app. Tell me when you start. Tell me when you stop.” And voila, in a few hours, you have a new app in your catalog that you can now write policies around.

The last big challenge I see with control of the usage of AI apps is regarding enterprise AI apps that are your bread and butter.

As an enterprise, you might say, “Here are my 25 most used sanctioned AI apps, and I have enterprise-level agreements with these LLM providers so that they don’t store my data, they don’t train on my data, the content that I generate belongs to me and not to someone else, and so on, so forth.”

And you might feel safe, but it’s a false sense of security, because your users are not using those specific apps the way you intended them to.

Users might come in and use a free version of that app. They might access it with their personal credentials. For example, with ChatGPT, enterprises will use the Team or the Enterprise license, but a user could start with a version where they don’t even log in, a personal account, a Plus account, a Team account, and so on, so forth, where for each type of entitlement the risk is very different. Their terms and conditions on whether you can train, store, and so on are very different.

So the last step, or challenge, with AI usage control is to understand not just the app and what it is, but to decode it deep down to understand the entitlement type. And the intentions: if you’re using ChatGPT, are you just typing in a prompt and getting a response? Or are you doing things like running agent mode, running deep research, editing a canvas, and so on? What exactly are you doing with that app?

An understanding of that intention, and an understanding of that entitlement, which tells you what risk you’re taking on, is essential and key for these top enterprise apps that are sanctioned in the enterprise. You have to be able to give them special treatment and go deeper, so that you really expose all the risk that is associated even with those sanctioned apps, and so that you prevent usage in a way that is not secure for your enterprise. I’m going to call that deeper decode for enterprise apps.

So there you go. That’s my short list of five things that I see as big challenges when it comes to good, proper control of AI usage in a modern enterprise. Thank you.