How to Monitor Employee AI Usage: A Map of the Tool Categories

If you lead engineering or security at a company where people have started using AI seriously, you have probably asked some version of this question: how do I see what my team is doing with AI? It sounds like one question. It is not. It is at least five, and the reason the market feels so confusing is that dozens of vendors answer different ones using nearly identical vocabulary. Every website in this category promises visibility, prompt-level insight, policy enforcement, and audit trails. Very few explain which problem they are actually solving.

This article is a map. It sorts the tools into five categories, explains the question each category answers, names the real products in each, and gives you a way to figure out which one you need. We build a tool in one of these categories, and we will say clearly where it fits and - more usefully - where it does not.

First, decide which question you are actually asking

Before comparing any products, write down the sentence that would make you satisfied. In our experience, it is almost always one of these five, and they are not variations of each other. They require different architectures, are sold to different buyers, and cost wildly different amounts.

• Did confidential data leave the company through an AI tool? - a data-egress question.
• Which AI tools are people using without approval? - a shadow-IT inventory question.
• Is the AI product we are building safe to ship? - an application security question.
• Is our own AI feature working well and what does it cost? - an observability question.
• What did AI actually build for us, and can we reconstruct why? - a provenance question.

If more than one of these matters to you, you need more than one tool. There is currently no single product that answers all five well, and any vendor implying otherwise is stretching. The categories below map one-to-one onto the questions above.

Category 1: Network and proxy DLP

These are the secure access service edge vendors - companies that already sit in your network path and have extended their existing inspection engines to cover AI traffic. Netskope One AI Security and Zscaler AI Security are the two clearest examples.

Architecturally, they inspect traffic inline. Netskope examines every prompt and response in real time, matching against data loss prevention rules for source code, personally identifiable information, and intellectual property, and it maintains a risk index covering tens of thousands of SaaS and AI applications. Zscaler routes AI traffic through its Zero Trust Exchange and offers warn, block, and isolate responses, alongside shadow AI discovery and runtime protection against prompt injection.

The strength of this category is coverage: because they intercept traffic rather than integrate with individual applications, they see AI tools nobody told them about. The cost is that you must be willing to put a vendor in your network path, and these are enterprise sales with enterprise price tags and enterprise deployment timelines. Buy here if the sentence that keeps you up at night is about data leaving the building.

Category 2: Endpoint and browser governance

This category attacks the same egress problem from the device instead of the network. Microsoft Purview is the dominant option, particularly if you are already a Microsoft shop. Data loss prevention for Microsoft 365 Copilot became generally available in 2026, and Purview can register ChatGPT Enterprise as a governed data source, bringing audit, classification, insider risk management, and eDiscovery to those interactions.

There is an important caveat worth knowing before you assume Purview covers everything. Governance of Microsoft's own AI surfaces is deep and native. Coverage of third-party consumer tools - someone pasting a customer list into ChatGPT in a personal browser tab - depends on additional components: Endpoint DLP, Defender for Cloud Apps, and the Purview browser extension. That is more licensing and more deployment than the headline suggests.

Startups compete here by being simpler to deploy. Aona.ai focuses on surfacing shadow AI across a workforce, redacting sensitive content before it reaches external tools, and coaching employees in context when they are about to do something risky. ThreatLens classifies sensitive data in prompts at the moment of submission and then redacts, routes to an approved internal model, or blocks - logging the reasoning behind every decision.

Categories 1 and 2 answer the same question from different vantage points: did something sensitive leave? Both stop measuring the instant the prompt is sent.

Category 3: Securing the AI you build

This category is frequently confused with the first two because the marketing language overlaps almost completely, but it addresses a genuinely different problem. It is not about your employees at all. It is about the AI applications and agents your company ships to its own customers.

Palo Alto Networks Prisma AIRS is the most complete example: an AI runtime firewall that defends against prompt injection and model denial of service, model scanning that blocks vulnerable models from reaching production, automated red teaming that attacks your system with crafted prompts and returns a risk score, and posture management for agents running across cloud and SaaS platforms. F5 AI Guardrails occupies a similar position as an inference-time policy gateway, model-agnostic and deployable across cloud and on-premises, with a threat research pipeline feeding it new attack patterns continuously. Lasso Security approaches it from discovery outward: an AI bill of materials inventorying your agents, models, system prompts, and tools, then posture management, red teaming, and runtime enforcement at the gateway layer.

If you are not building AI features into a product you sell, you can skip this category entirely. If you are, none of the tools in categories 1 and 2 will help you, no matter how much their websites sound alike.

Category 4: LLM observability and evaluation

This is the developer-facing sibling of category 3, and it is where most engineering teams building AI features spend their time. Langfuse, LangSmith, PromptLayer, Helicone, and Braintrust all live here. They instrument your own application code to capture traces of model calls, version and test prompts, run evaluations against reference datasets, and report token consumption and cost per feature or per user.

Adjacent to these, and worth knowing about because it solves the budget half of the problem outright, is LiteLLM. It is an open-source AI gateway: your applications call it instead of calling providers directly, and in exchange you get one interface across more than a hundred providers, virtual keys instead of distributed provider credentials, spend attribution per key, team, and organization, and hard budget limits that stop a request rather than merely recording it. It is free to self-host under an MIT licence, with an enterprise tier for single sign-on and role-based access. If your question is how to cap and attribute API spend across an organization, start there.

The distinguishing characteristic of this whole category is that it only ever sees traffic you deliberately route through it - via a software development kit, or by pointing your applications at a gateway. That makes it precise and rich for the AI product you build, and blind to everything outside that path. It is also the practical limit on using a gateway to watch coding assistants: you can point some of them at a proxy, but tools that authenticate through their own subscription and backend cannot be redirected at all, so coverage ends up partial in a way that is easy to mistake for complete.

Category 5: Code provenance

Here is the gap that the first four categories leave open, and the reason we built PromptWake. Every tool above stops at the moment a prompt is sent. It was allowed, blocked, redacted, traced, or logged - and then the record ends. None of them can tell you what the AI actually produced, or connect it to what is running in production today.

That gap matters more each quarter, because AI now writes a substantial share of shipped code. Version control tells you what changed and who committed it. It does not tell you that a particular authentication middleware came from a specific twenty-message conversation in which a developer explicitly instructed the model not to touch the session logic. When a regression appears in that session logic three weeks later, the most valuable evidence in the post-mortem is exactly the record nobody kept.

Code provenance tools capture the complete chain: the prompt, the model response, and the diff that resulted. PromptWake does this by running as a local daemon that reads the history the AI tools you already use write to disk - Claude Code, Cursor, GitHub Copilot in VS Code, OpenCode, and roughly twenty more - with no API keys and no provider configuration. Secrets are redacted before anything is stored, and on the free tier nothing leaves the machine. Teams can share a workspace with a combined timeline, an audit log, and role-based access.

We want to be equally clear about what this category does not do, because being mistaken for a security product helps nobody. Code provenance tools do not sit in the network path. They do not block anything. They do not watch browser tabs or stop a developer from pasting a customer record into a chat window. If that is your requirement, buy from category 1 or 2 - provenance is not a substitute and we will tell you so.

Choosing without buying five products

A practical way to sequence this is to start from the consequence you are trying to avoid rather than the capability you want to acquire.

• If the worst outcome is a regulator or customer learning that confidential data reached a public model, start with category 1 or 2. Choose by architecture: network path if coverage matters most, endpoint if deployment speed matters most.
• If the worst outcome is your own AI feature being jailbroken by a customer, start with category 3, and add category 4 for quality and cost.
• If the worst outcome is an incident nobody can explain because the AI conversation that produced the code is gone, start with category 5.
• If you are a Microsoft-centric organization, evaluate Purview first regardless - you may already own a meaningful part of categories 1 and 2.

The categories are complementary rather than competitive, and a mature setup eventually spans several. A realistic end state for a mid-sized engineering organization looks like one egress control from category 1 or 2, observability from category 4 if the company ships AI features, and provenance from category 5 covering how the engineering team itself builds. That is three tools solving three genuinely different problems, not three vendors solving one.

Ask which sentence would make you satisfied. If you cannot write it down, no product in any of these five categories will make you feel covered.

The question worth asking your vendors

Whichever direction you go, there is one question that cuts through the overlapping marketing language quickly: what happens after the prompt is sent? Vendors in categories 1 and 2 will describe a decision - allowed, redacted, blocked - and an audit entry. Vendors in category 3 will describe an attack being deflected. Vendors in category 4 will describe a trace and a cost figure. Only category 5 will describe the code that came out the other end.

None of those answers is wrong. They are answers to different questions. Knowing which question is yours is most of the work, and it is the part no vendor can do for you.