Most organizations already know they have a shadow AI concern, but they don’t always know how big it might already be.
As a quick definition, Shadow AI encompasses any AI running in the business that nobody approved, inventoried, or assigned an owner. This means much more than employees using a public chatbot. Instead, it may include:
Each of those puts company data somewhere nobody reviewed, and only some of them happen in a browser. Security teams can usually name the obvious tools, block some, restrict others, and write policy around the rest. What they cannot always answer is the more fundamental question:
What AI is running across the enterprise?
I ask this question in nearly every security conversation I’m in, and the honest answer is usually some version of “we’re not sure.” That’s a reflection of how fast this has moved. But it does force a decision about architecture. Do you put controls at the point where employees interact with AI? Or do you build broader discovery across the environment and govern what you find through the systems where enterprise risk, ownership, and remediation already live?
Both approaches have value, and they solve different parts of the shadow AI problem. They also leave you in very different positions once discovery starts finding things. Identifying an unsanctioned AI tool is useful. Knowing who owns it, what risk it creates, whether it should be approved, and what happens next is where governance begins.
The enterprise browser is the clearest expression of the first philosophy. Replace Chrome or Edge with a managed Chromium build (like Island), and governance sits directly at the point of interaction. If someone pastes source code or customer information into a chatbot, inline data loss prevention (DLP) can redact the text, block the paste, or flag the session in real time. That control is granular, it works off-network, and it stops data before the model ever sees it. When I see a team evaluating one of these, I understand why. It demos beautifully, and the protection it offers is real.
The limits are structural rather than a matter of product maturity. A browser secures web apps, but has no view of a developer running a local model, an unauthorized API key, a desktop AI client, a command-line script, or an unmanaged device doing inference on the network.
On a more immediate level, this also asks an entire workforce to abandon a browser they already use, which makes it a change management program as much as a security control. And when the tool does catch something, the output is a blocked action and an alert in its own console, with no case, no owner, and no SLA attached. Your analyst still has to go find the culprit.
The second architecture separates the two jobs and assigns each to something built for it. Discovery runs at the network layer with Armis Centrix, and governance runs in AI Control Tower, inside the platform where enterprise work already happens.
Armis Centrix monitors network traffic, APIs, endpoints, cloud, and IoT passively, without an agent on every device, and identifies AI activity across the estate, sanctioned and unsanctioned alike. The agentless approach works by watching traffic and connecting to existing infrastructure, which is how it reaches assets that were never built to run an agent, like IoT sensors, OT controllers, medical devices, and even personal phones. Because it watches the traffic rather than the window, it catches AI use in desktop applications, IDEs, API calls, and unmanaged devices.
Detection works on metadata, headers, and traffic patterns, so no SSL decryption is required to make it useful. That last point matters more than it sounds, because it takes the network team’s biggest objection off the table before the first meeting ends.
In evaluations we’ve observed, that discovery spans dozens of major AI services at once and resolves them into a single asset view, stitched together from directory and endpoint sources. It is usually the first time a security team has seen its own estate that clearly, and the reaction in the room tends to be quiet for a moment.
If you last looked at this market a year ago, one thing has changed underneath the comparison. ServiceNow acquired Armis and Veza and launched Autonomous Security & Risk at Knowledge 2026, bringing asset intelligence and identity governance into the platform itself. Discovery and governance now sit on one roadmap, so a buyer weighing a standalone point tool is weighing it against a platform rather than against an integration project.
ServiceNow AI Control Tower is where these findings become a program. It gives you one place to inventory AI assets, secure AI actions, and govern AI activity, with readiness assessments, oversight of models, skills, and agents, governance roles and approval workflows, and analytics for usage and adoption.
Discovered AI is enriched as a configuration item with lineage, ownership, and relationships, and mapped to the business services it touches. It also does discovery of its own, pulling AI assets from the hyperscalers and agent frameworks through Service Graph Connectors, which is worth knowing before you assume network discovery is the only way in.
Findings arrive as AI cases with assignment groups, notifications, and dashboards, mapped against the risk register, with a route back to the detection console for the analyst who needs the underlying evidence. One workflow, one audit trail.
I’ll be direct about the tradeoffs, because they come up in every technical evaluation. Network-level enforcement will block or flag traffic to an unsanctioned service, but it doesn’t read the text typed into a browser field the way inline DLP does.
The integration between discovery and governance also has to be designed. Service graph connectors have made that considerably easier, and it is still engineering work that belongs in the plan and the estimate.
The most common failure I see is treating discovery as the end of the project. A broad sweep across a large estate will return thousands of AI-touching assets, and a list of thousands of unreviewed assets is a backlog with no owner. I have watched teams celebrate that report on a Friday and inherit the problem on Monday.
What turns that list into an outcome is the triage path, and this is where AI Control Tower earns its place: an approved AI asset register, an exception and approval trail, a risk assessment tied to the IRM risk register the organization already maintains, and remediation that runs in the same queues as the rest of your IT and security work.
An Armis finding should land as an AI case in ServiceNow, update the CMDB, launch a vendor risk assessment against your IRM risk register, and open a guided path that walks the user toward an approved alternative. That chain is why the sequencing matters: visibility first, then governance, then control.
Ask any vendor to separate what ships in your release from what is on the roadmap. This market moves fast enough that capability which was roadmap in one release is generally available in the next, and the gap between a demo and your instance is the thing to pin down.
Two questions get you there. Which discovery and control capabilities are live in the release you are running? And for AI agents operating outside the platform, are you buying observability or actual control? A phased plan with dates holds up in a technical review. A capability claim that collapses under one question does not, and it takes the rest of your credibility with it.
The choice depends on the question you are trying to answer. If the question is, "How do we stop people pasting sensitive text into chatbots?" the point-of-interaction tool is a reasonable answer. If the question is, "What AI is running in our environment, who owns it, and what happens next?" then discovery has to reach beyond the browser, and the findings have to land somewhere that already has owners, workflows, and an audit trail.
For most ServiceNow customers, that “somewhere” is already installed. The organizations getting this right are extending the system of record they already run, so AI becomes another class of asset with a lifecycle. You are already invested in that ecosystem. The question I would put on the table is whether you extend it or stand up a second console beside it.
The part I care most about, though, is what this does to your relationship with the business. A browser tool is a restriction instrument by design. Its entire value is in what it prevents, and the security team that owns it becomes the team that says “no.” That works right up until it doesn’t, because a walled garden always gets worked around. People who need a tool to do their job will find one, and the ones who route around you are usually your most motivated employees.
Armis and AI Control Tower put you on the other side of that. Armis shows you what AI is currently running, AI Control Tower gives that AI an owner, a risk rating, and an approval path. Together they let you onboard new capability quickly because the review is a workflow rather than a committee. When a business unit asks for a model you’ve never heard of, you have a register to check it against, an assessment that takes days instead of quarters, and evidence for the auditor when it ships.
Your company is going to keep adopting AI whether or not security is in the room for it. The teams I work with have stopped trying to slow that down and started trying to see it, own it, and put a signature on it.
Blocking buys you a quiet quarter. Knowing what you have, who owns it, and how it got approved is what you will want on hand the first time a regulator, an auditor, or your own board asks the question.
--
If you’re scoping an AI governance program and weighing how discovery, risk, and remediation should fit together, let’s have a conversation.