When generative AI first arrived in the workplace, many organisations reached for the control they already trusted, which was the firewall. Block ChatGPT and the other obvious domains, and the problem appears to be dealt with. Having spent a large part of my career designing networks and security architectures, I understand the instinct. A block is decisive, and it is easy to report to a board.
In most of the organisations I speak to, however, the block hasn't stopped AI use. It has stopped the business from seeing it.
I saw exactly this in the early days of cloud. Many of the organisations I worked with had extensive use of Dropbox and similar services among their staff, regardless of which corporate storage solution they had invested in and regardless of whether it was officially blocked. It was common in organisations of every size, and in most cases nobody in IT knew the full extent of it until they went looking.
Why blocking tends to backfire
A firewall only sees traffic that passes through it. As soon as an employee works from home, tethers to a phone or switches to a personal device, the block no longer applies and neither does your visibility. The work carries on regardless: contracts get summarised, spreadsheets get pasted in and customer emails get drafted, just through personal accounts over home connections, with no record and no policy applied.
There is also a less obvious cost. A blanket block tells staff the organisation sees AI as a threat rather than a capability, and the people most likely to find productive uses for it are generally the ones most likely to work around the block, and the least likely to share what they've learned. The organisation keeps the risk and loses sight of the benefit, while the security team believes the issue has been addressed.
AI no longer lives at a single web address
Even on the corporate network, a domain block list is chasing a moving target. AI use in a typical business now includes browser chat tools on personal free-tier accounts, desktop apps and coding assistants installed directly on laptops, browser extensions that can read internal systems, AI features embedded in SaaS applications that are already approved, and agents and MCP servers that can read local files and act on a user's behalf, sometimes without generating any obvious web traffic.
New tools appear every week, so a block list is out of date as soon as it is published, and it can't distinguish a sanctioned enterprise account from a personal account on the same service. An unvetted MCP server connected to an HR system, for example, is exactly the kind of activity a domain block list was never designed to see.
The device is where AI use happens
Every one of those routes has one thing in common, which is that it runs on a device, and the laptop goes wherever the user goes. Discovery on the device gives you context the firewall never had: which tools are installed, whether a browser service, desktop app, extension, local agent or MCP server; which account each runs as, so a personal login shows up alongside the corporate tenant on the same service; what each is set up to connect to; and the same view whether the laptop is on or off the corporate network. It doesn't read prompts or documents; data loss prevention does that job.
That context changes the question being asked. Instead of "is AI allowed?", you can ask whether a particular tool, used through a particular account and connected to particular systems, is acceptable, and that is a question governance can actually answer.
It does need doing carefully. Monitoring how people use AI raises legitimate privacy questions, particularly in countries with strong employee protections, so the aim should be visibility of the AI estate rather than surveillance of individuals, designed with HR, legal and, where they exist, works councils involved from the start.
Other tools are converging on the same conclusion. Network security platforms that once watched only traffic now offer endpoint agents for AI, endpoint security vendors detect AI applications and local agents, and Microsoft now flags some local agents on managed Windows devices. Many organisations will find they already own part of this capability. The harder question is what happens next: who reviews what is found, who decides whether it is acceptable, and whether anyone tells the board. Finding AI is becoming a feature of many tools. Deciding what to do about it is still a business decision.
Phones, tablets and personal devices
Discovery on a laptop has a clear boundary: it covers the computers you manage. Phones and tablets are a different case. The major AI services all have mobile apps, AI assistants are increasingly built into phone operating systems and keyboards, and a lot of quick AI use happens on a phone, often a personal one.
Mobile platforms are deliberately locked down, so the inventory you can build on a laptop isn't available in the same way. The practical answer is to govern the company's data and access rather than the handset:
- On company-owned phones and tablets, mobile device management (MDM) controls which apps are installed, so the approved AI app can be provided and others kept off.
- On personal phones, app protection policies, often called mobile application management, keep company data inside managed apps. Someone can't copy a client email from their work mail app into a personal AI app, and the organisation never manages or sees the rest of the phone.
- Conditional access means company systems can only be reached from compliant devices or managed apps.
- Data loss prevention, where it is in place, controls what sensitive data can leave, whatever the device.
None of this gives you the same picture you get from a laptop, and on a personal phone it shouldn't try to. What it does is bring mobiles inside the AI policy, so the gap is a known and managed one rather than a blind spot.
From blanket blocks to proportionate policy
With device-level visibility, AI governance no longer has to be on or off. It can become a set of proportionate rules that let people use AI safely and productively, as the examples below show.
| Situation | Blanket firewall block | Device-level policy |
|---|---|---|
| Staff member uses the approved corporate AI tenant | Often blocked along with everything else | Allowed and logged |
| Same tool, personal free account | Blocked on-site, invisible at home | Flagged; user nudged to the corporate account |
| Unreviewed browser extension reading internal pages | Not seen | Detected; your IT team removes it through endpoint management |
| Staff member uses a personal AI app on their phone | Not seen once off the office Wi-Fi | Company data kept inside managed apps; the approved AI app offered on the phone |
| Finance team pastes customer data into an unapproved tool | Invisible if off-network | The unapproved tool is found and the team pointed to an approved one; with DLP in place, the paste itself can be prevented based on data sensitivity |
| Developer runs a local coding agent with file access | Not seen | Inventoried and risk-assessed |
The organisation keeps the productivity gains and manages the risk where it sits.
Visibility first, then control
A firewall block feels like control, but mostly it takes away your view. Moving visibility to the device turns AI from a hidden risk into something that can be managed, and makes it possible to say yes to the uses that create value.
If you'd like to understand what AI is really in use across your estate, evidence from your own devices is the quickest way to find out. Our AI review starts with a week of read-only discovery on Windows and Mac computers agreed in advance with your IT team, and a 30-minute walkthrough is the place to start.