How Do I Find Out What AI Tools My Staff Are Actually Using?

Most organisations discover their AI exposure the same way: someone senior asks a simple question, and nobody can answer it. The honest answer is usually that the tools everyone assumes would show this, the firewall, the proxy, the identity provider, were built to watch something else. This guide sets out what each of them actually sees, where the gaps are, and the sequence that produces a real answer inside a fortnight.

Why do network logs not show what AI tools staff are using?

Network logs prove that a device reached a domain. They do not show who was signed in, what was typed, or whether anything sensitive left the organisation. A log entry for chatgpt.com is equally consistent with a developer reading the pricing page and a finance manager pasting a customer list into a prompt.

There is a second problem that gets less attention. Traffic inspection sees a session, not a page, so it cannot separate an AI feature from the product it lives inside. When a chatbot is embedded in a tool your organisation already pays for, the traffic looks exactly like ordinary use of that tool.

Does single sign on give me a complete picture of AI use?

Single sign on, the system that lets staff use one corporate identity across many applications, shows you the tools you have already sanctioned. That is precisely the population you are not worried about. It is silent on anyone using a personal account, which is where the majority of the exposure sits.

The scale of that gap is now measured. Akamai found that 47.11% of enterprise AI conversations run through personal identities rather than corporate managed accounts (Source: Akamai, State of the Internet: Enterprise AI Usage Risk Report 2026, August 2026). Read that carefully, because it is usually quoted backwards. It is not saying that half of staff use AI with their work email. It is saying that close to half of the AI activity happening in the business is invisible to the identity system you would think to check.

What is shadow AI, and why does a vendor list miss it?

Shadow AI is AI capability in use inside an organisation that IT has not reviewed or approved. It is a wider problem than shadow IT because it arrives through three doors at once, and only one of them looks like a purchase.

• Direct tools. Someone opens a chatbot in a tab and signs in with a personal email. No procurement, no invoice, nothing to find in a vendor list.
• Embedded features. Your existing SaaS vendors ship AI inside products you already bought. The contract predates the feature, so nothing triggered a review.
• Installed apps. Progressive web apps, browser based applications that install to the desktop and open in their own window, look like native software to the user and like ordinary web traffic to the network.

A procurement led audit finds the first category only when someone paid for it, and finds nothing in the other two. That is why organisations that run a thorough vendor review still get surprised.

What about browser extensions, are they part of this?

Browser extensions are the part of this problem that most reviews skip, and they carry more privilege than the tools people worry about. Akamai's research found that almost 75% of AI browser extensions demand high or critical permissions (Source: Akamai research, 5 August 2026). Permissions at that level typically allow an extension to read and change the content of pages the user visits, which includes the internal systems they are signed in to.

The same research reported that 16.3% of AI browser extensions contain known CVEs, publicly catalogued security vulnerabilities (Source: Akamai research, 5 August 2026). An extension installed by one person, once, keeps that access until somebody removes it.

Why does the browser see what other controls cannot?

The browser sees it because that is where the work happens. Forrester found that more than 70% of corporate work now takes place inside a browser (Source: Forrester, Digital Workplace and Employee Technology Survey 2025). Every other control observes a different object, and each one is genuinely good at the object it was built for.

• Application allowlisting observes processes. A tab is not a process.
• Firewalls and traffic platforms observe flows. A flow does not carry intent.
• Document data loss prevention, or DLP, the practice of detecting sensitive content before it leaves, observes files. A pasted paragraph is not a file.
• TLS inspection observes payloads in transit, and only after the browser has already assembled them.

None of these takes the in page interaction as the object. That is a placement argument rather than a coverage argument, and it is the one a security architect will accept, because it does not require anyone to concede that their existing controls are bad.

What should I actually do first?

Run a read only discovery for two weeks before you write a single line of policy. You want a list of what is genuinely in use, by how many people, through which accounts, and holding which permissions. Policy written before that list exists tends to ban the tools nobody uses and miss the ones everybody does.

Three questions make the output useful rather than merely long. Which tools are being reached through personal rather than corporate accounts? Which of them already sit inside software the organisation pays for? Which extensions are installed, and what can they read?

Which tools can actually run that discovery?

Tools that run inside the browser can, because that is the only vantage point where personal accounts, embedded AI features and installed extensions are all visible at once. Akamai Workforce Protector is the platform we deploy for this, through an extension covering Chrome, Edge, Firefox and Safari, with an optional endpoint agent when coverage needs to extend to desktop AI applications and AI enabled IDEs.

Two details matter to the people who will review the decision. It installs through the device management you already run, with no proxy and no traffic redirection, so there is nothing to re-architect. Classification happens inside the browser, and Akamai's position is that content, including personal information, stays there while only alerts reach the cloud console. For an organisation with Australian privacy obligations, that is an architectural answer rather than a contractual promise.

How does David and Goliath help with this?

We run the discovery, read the output, and turn it into a governance position your executive can actually sign. That means a fortnight of read only observation, a ranked list of what is in use and what it can reach, and a recommendation that separates the tools worth sanctioning from the handful worth stopping.

The follow on question most teams ask next is what their existing licences already cover, which we work through in does Chrome Enterprise Premium cover Safari. If you would rather start with the conversation, book a call and bring whatever your current logs already tell you.