AI Usage Monitoring: Employee and Agent AI Visibility

Most organisations cannot say which AI services their people and agents use each day, what data goes into them, or which identity made each call. Discovery exercises find shadow AI once; usage monitoring keeps that picture current and turns it into evidence: who used which model, through which channel, with what class of data, and at what cost. This guide covers the telemetry sources that give that visibility (security service edge and CASB, enterprise browsers, endpoint agents, identity provider logs, AI gateways and platform audit logs), how to monitor AI agents and service identities as well as employees, what to capture without building a surveillance system, and the privacy and works council rules that shape the design. It is written for security engineers, SOC leads and privacy officers building an AI monitoring capability.

Key takeaways

No single source sees everything. Network inspection sees browser traffic to AI sites, the AI gateway sees sanctioned API calls, platform audit logs see in-product copilots, and only endpoint or browser controls see desktop apps and extensions.
Agents need identities before they can be monitored. Per-agent credentials routed through a gateway or a logged platform API turn token spend and model calls into attributable events.
Start with metadata, not prompts. App, user, data classification and volume answer most questions; prompt content capture should be limited, justified and access-controlled.
Employee monitoring law applies. In the UK the ICO expects a lawful basis, transparency and usually a DPIA; in Germany works councils have co-determination over technical monitoring and must be told about AI in work processes.
Measure coverage and action, not alerts. Track the share of AI traffic that is attributable, the share flowing through sanctioned channels and time to act on a new unsanctioned service.

What AI usage monitoring covers

AI usage monitoring is the continuous collection and analysis of telemetry about interactions with AI services. It sits between three related disciplines and borrows from each:

Discovery finds AI applications, agents and MCP servers that exist. See the Shadow AI Discovery Guide.
Data loss prevention inspects and blocks sensitive content in prompts and uploads. See the Generative AI Data Loss Prevention Guide.
Agent observability traces what an agent did step by step for debugging and incident response. See the AI Agent Observability and Incident Response Guide.

Usage monitoring answers the operational questions in between: which services are used and by whom, whether use matches the acceptable use policy, which identities (human or non-human) consume models, how spend and volume trend, and where to direct DLP, training or blocking. The output feeds the AI register, the SOC and governance reporting.

Population	Typical channel	Who it is	Primary visibility point
Employees using public AI websites	Browser to SaaS AI	Human user, often with a corporate or personal account	SSE/SWG/CASB, enterprise browser
Employees using in-product copilots	Embedded AI in SaaS suites	Human user via SSO	Platform audit logs
Desktop AI apps, IDE assistants and extensions	Native app or extension to API	Human user, sometimes a personal API key	Endpoint agent, browser extension management, network
Third-party AI apps granted access to corporate data	OAuth grant to SaaS	Non-human: OAuth client acting for a user	Identity provider and SaaS consent logs
Internal applications and agents calling models	Server to model API	Non-human: service account, API key, workload identity	AI gateway, cloud model invocation logs

Telemetry sources compared

Source	What it sees	Blind spots	Best use
SSE, secure web gateway and CASB discovery	Destinations, users, bytes up and down, app category and risk score; with TLS inspection, some request content	Unmanaged devices off the network path, certificate-pinned apps, traffic not routed through the service	Broad inventory of AI SaaS use, sanction and block decisions
Enterprise browser or managed browser policy	Pages, paste and upload events, extensions, account used	Other browsers unless blocked, native desktop apps	Paste and upload controls, personal versus corporate account separation
Endpoint agent	Processes, local apps, network connections, file access	Content in encrypted sessions, unmanaged devices	Desktop AI apps, local models, CLI and IDE assistants
Identity provider and SaaS audit logs	SSO sign-ins to AI apps, OAuth consents and scopes	AI services used without SSO	Third-party AI apps with access to corporate data
AI gateway or LLM proxy	Every routed call: caller identity, model, tokens, latency, optionally prompt and response	Calls that bypass it with direct provider keys	Agents, internal apps, spend control, per-identity attribution
Cloud and AI platform audit logs	Model invocations or copilot interactions with caller identity and resources accessed	Only that platform; some logging is off by default	In-product copilots, managed model services

Examples of platform features

These illustrate the kind of telemetry available; equivalent features exist in other platforms.

Cloud app discovery: Microsoft Defender for Cloud Apps lists AI services under a Generative AI category in its cloud app catalog with risk scores. A discovery policy with the condition "Category equals Generative AI" alerts on newly seen apps, and tagging an app Unsanctioned blocks it on devices onboarded to Defender for Endpoint.
Copilot and AI app audit: Microsoft Purview audit uses record types CopilotInteraction (Microsoft copilots), ConnectedAIAppInteraction (registered custom or third-party AI apps) and AIAppInteraction (third-party AI apps observed through network or browser DLP). Records include AppIdentity, AccessedResources with sensitivity label IDs, a JailbreakDetected flag per message and agent identifiers. Logging of non-Microsoft AI interactions is a pay-as-you-go feature with 180-day retention.
Managed model invocation logs: Amazon Bedrock model invocation logging is disabled by default. When enabled it records Converse, ConverseStream, InvokeModel and InvokeModelWithResponseStream calls to CloudWatch Logs or S3, including the caller's IAM or STS ARN in identity.arn, optional requestMetadata tags, token counts and request and response bodies up to 100 KB.
Gateway policies: Azure API Management's AI gateway offers llm-token-limit (tokens per minute or quotas keyed on subscription, IP or any expression) and llm-emit-token-metric (token metrics to Azure Monitor with custom dimensions such as API ID or a user ID header), and can log prompts, completions and token usage to Application Insights.

Decision guidance: a small organisation with mostly SaaS use gets the most from the SSE or browser layer plus identity provider consent logs. An organisation building agents should make an AI gateway the only route to model providers and treat direct provider keys as an exception. Large regulated organisations need all layers and a common schema in the SIEM. See the SASE and SSE Guide, the Enterprise Browser and Browser Security Guide and the AI Gateway and LLM Gateway Guide.

Monitoring AI agents and service identities

Agent traffic does not pass through a browser and often uses static API keys, so the controls for employees miss it. The fix is identity first.

One identity per agent: issue each agent or application its own workload identity, role or gateway key with a named owner. A shared key makes every log line ambiguous. See the Agentic AI Identity Guide.
Route through a logged path: require agents to call models through the gateway or a platform with invocation logging enabled; block egress to provider API domains from workloads that should not call them directly.
Tag calls: attach agent name, environment and business owner as request metadata (Bedrock requestMetadata, gateway headers) so usage can be grouped by owner, not only by credential.
Budgets per identity: token limits per agent cap the damage from loops and stolen keys, the risk OWASP describes as LLM10:2025 Unbounded Consumption.
Watch the control plane: alert when invocation logging is disabled, when new model access is requested and when a key is used from a new network location. The LLMjacking campaigns show attackers checking whether invocation logging is enabled, sending quiet validation calls and then generating tens of thousands of requests on victims' accounts.
Standard telemetry: the OpenTelemetry GenAI semantic conventions define spans, metrics and events for GenAI clients and MCP, which helps keep gateway, application and agent framework telemetry consistent. Check the project for current status before relying on attribute names.

For the detection logic built on these signals, see the AI Agent Behaviour Baselining and Anomaly Detection Guide.

What to capture: metadata versus content

Level	Fields	Answers	Privacy weight
1. Service metadata	Destination app, category, timestamp, device, bytes	Which AI services are used and how much	Low; still personal data when linked to a user
2. Identity and context	User or NHI, account type (corporate or personal), department, sanctioned status	Who uses unsanctioned services; which agents consume most	Moderate
3. Data classification	Sensitivity labels or DLP match types on prompts and uploads, without content	Whether sensitive data leaves through AI	Moderate
4. Usage economics	Model, input and output tokens, cost, latency	Spend, abuse of keys, runaway agents	Low for agents, moderate for named users
5. Content	Full prompts, responses and files	Incident investigation, quality and safety review	High; may include special category data and third parties' data

Default to levels 1 to 4 for employees. Capture level 5 for agents and internal applications where it is needed for debugging or safety review, with short retention and restricted access. For employees, collect content only where DLP has matched, or for a defined investigation, and document why. Remember that prompts frequently contain credentials and customer data: the monitoring store becomes a sensitive system in its own right, the risk OWASP LLM02:2025 Sensitive Information Disclosure describes for LLM applications.

Privacy, employee monitoring and works councils

Monitoring AI use is monitoring workers. The design must satisfy data protection and labour law before it is switched on.

Lawful basis: the ICO's monitoring workers guidance says consent is usually inappropriate in employment and contract is rarely suitable; legitimate interests is the most flexible basis but needs a documented legitimate interests assessment covering purpose, necessity and balancing.
DPIA: the ICO says a DPIA must be completed before high-risk monitoring, giving keystroke monitoring as an example; prompt content capture is comparable in intrusiveness and should go through one.
Transparency: workers must be told about monitoring in accessible language; covert monitoring is for exceptional cases such as suspected criminal activity, authorised by senior management and time-limited.
Proportionality: no monitoring "just in case"; choose the least intrusive means and review for function creep, for example AI usage data later used for performance management.
Special category data: prompts can reveal health or trade union information, which needs an additional condition even when captured incidentally.
Consultation: the ICO says employers should seek and document the views of workers or their representatives. In Germany, section 87(1) no. 6 of the Works Constitution Act gives the works council co-determination over introducing technical devices designed to monitor employees' behaviour or performance, section 90(1) no. 3 requires the employer to inform the works council about working procedures including the use of AI, and section 80(3) treats an expert's advice on AI as necessary.
Rights: workers can make subject access requests for monitoring data and object to processing based on legitimate interests.

The ICO guidance was under review following the Data (Use and Access) Act when read, so check the current version. See the AI and Privacy Guide, the DPIA Guide and the Insider Risk from AI Tools Guide.

How to implement

Define purpose and policy. Write down what monitoring is for (data protection, security, cost, licence planning) and align it with the AI acceptable use policy. See the AI Acceptable Use Policy Template.
Consult and assess. Complete the legitimate interests assessment and DPIA, engage the works council or employee representatives, and publish the worker privacy notice.
Turn on passive discovery. Enable AI app discovery in the SSE or CASB, identity provider consent reporting and platform audit logs in observe-only mode for four to six weeks to build a baseline.
Classify services. Mark each discovered AI service sanctioned, tolerated or unsanctioned, record owners in the AI register and publish the sanctioned list.
Bring agents onto the gateway. Issue per-agent identities, enable invocation logging, set token budgets and alert on logging changes.
Pilot enforcement. For a pilot group, move from monitor to warn (coaching pages) to block for unsanctioned services, and enable paste or upload controls for labelled data. Measure helpdesk tickets and bypass attempts.
Roll out in rings by department, keeping an exception process and the ability to revert a block to warn within minutes if a business process breaks.
Review quarterly. Re-run the DPIA if scope changes, prune retention and report metrics to governance.

Detection use cases and metrics

Signal	Likely meaning	Response
New AI service with sensitive data uploads	Shadow AI adoption with data exposure	Contact user and owner, assess service, sanction or block
Large uploads to AI sites from a leaver or high-risk user	Possible exfiltration over web service (ATT&CK T1567)	Insider risk triage under the agreed process
Corporate data sent to a personal AI account	Policy breach, data outside contractual protection	Coach, then enforce account separation in the browser
New OAuth grant to an AI app with broad mail or file scopes	Third-party AI with standing access to corporate data	Review scope, owner and need; revoke if unjustified
Token spike or calls from a new location on an agent key	Runaway agent or stolen key	Throttle, rotate the key, investigate
Invocation logging disabled	Possible attacker evasion or misconfiguration	Re-enable, investigate the change author

Metrics that show it works:

Attribution coverage: percentage of AI calls and sessions attributable to a named human or non-human identity.
Sanctioned share: percentage of AI usage volume through sanctioned services and the gateway.
Time to decision: median days from first sighting of a new AI service to a sanctioned or blocked decision.
Agent hygiene: percentage of agents with a unique identity, an owner and a token budget.
Sensitive data events: DLP matches on AI channels per 1,000 users, trended after training and controls.
Privacy compliance: content records past their retention date (target zero).

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	DE.CM-03, DE.CM-09, ID.AM-02	Monitoring personnel activity and technology usage; monitoring software and data; inventory of services
NIST SP 800-53 Rev. 5	AU-2, AU-6, AU-11, AU-12, SI-4	Event logging, review, retention, generation and system monitoring
NIST SP 800-53 Rev. 5	AC-20, PL-4, CM-8, PT-5	Use of external systems, rules of behaviour, inventory, privacy notice
CIS Controls v8.1	Controls 2, 3 and 8	Software asset inventory, data protection, audit log management
ISO/IEC 27001:2022 Annex A	5.10, 5.34, 8.12, 8.15, 8.16	Acceptable use, privacy and PII, data leakage prevention, logging, monitoring activities
OWASP Top 10 for LLM Applications 2025	LLM02, LLM10	Sensitive information disclosure; unbounded consumption
MITRE ATT&CK	T1567, T1567.002	Exfiltration over web service and to cloud storage

Common failure patterns

Network-only visibility: relying on the web gateway while agents call model APIs directly from cloud workloads that never pass through it.
Shared agent keys: one provider key for many applications, so a spike cannot be attributed and rotation breaks everything at once.
Logging off by default left off: managed model services where invocation logging was never enabled, discovered only during an incident.
Capturing everything: storing every employee prompt indefinitely, creating a sensitive data store and a works council dispute.
Blocking without alternatives: blocking public AI before a sanctioned option exists, which pushes use to personal devices outside monitoring.
Ignoring OAuth grants: watching traffic but not the consents that give AI apps standing access to mail and files.

Lessons from incidents

Samsung, 2023: within weeks of allowing ChatGPT, engineers pasted source code and a meeting transcript into it in three separate cases; Samsung responded with a 1,024-byte prompt cap and then restricted generative AI tools. Usage monitoring with data classification would have shown the pattern before it became a ban. See the Samsung ChatGPT Source Code Leak.
Vercel and Context.ai, 2026: an employee signed up to a consumer AI office suite with a corporate Google account and granted it full access; when the AI vendor was breached, the stolen OAuth token gave the attacker the employee's Workspace account and a path into Vercel. Monitoring consents to AI apps, not just traffic, would have surfaced the grant. See the Vercel Context.ai OAuth Breach.

Practitioner checklist

Document the purpose of AI usage monitoring and link it to the AI acceptable use policy.
Complete a legitimate interests assessment and DPIA, and consult employee representatives or the works council before go-live.
Enable AI app discovery in the SSE or CASB and review the Generative AI category weekly.
Report OAuth consents to AI apps from the identity provider and review broad scopes.
Give every agent and AI application its own identity, owner and token budget.
Route agent model calls through a gateway or enable platform invocation logging, and alert if logging is disabled.
Default to metadata and classification; restrict, justify and time-limit content capture.
Set retention for AI monitoring data and restrict access to it.
Report attribution coverage, sanctioned share and time to decision to governance each quarter.

Standards and references

Related NHI Mgmt Group resources: Shadow AI Discovery Guide · Generative AI Data Loss Prevention Guide · AI and Privacy Guide · Global AI Regulation Map

AI Usage Monitoring Guide: Visibility into Employee and Agent AI Use