Two things happen on a managed laptop within a minute of each other. A staff member launches a desktop AI client they installed at home, and the client opens a connection to an interface endpoint. In the security console afterwards, the first appears as a row with a process name, a command line, a parent process, a signing certificate and a user. The second appears as a row with a destination, a port and the process that opened it. What is not there, anywhere, is the sentence they typed.
The obvious reading is that the product has a gap. It does not. The agent is running privileged on that machine, with the power Chapter 14 described, and the record still stops exactly there. Three separate constraints put it there, and they are worth separating because they fail in different ways and are fixed, where they can be fixed at all, by different means. The first is what the sensor is positioned to observe. The second is what the pipeline can afford to carry. The third is what encryption does at the application layer, which Chapter 5 settled and which no endpoint product overturns.
Chapter 14 promised that this chapter would develop syscall observation into endpoint detection properly, and Chapter 17 promised that Part Four would own it. This is that chapter. It also underwrites two more: in a Microsoft estate the same agent is the discovery sensor of Chapter 24, and the same onboarding act enables the endpoint data loss prevention of Chapter 25.
The sensor and where it is allowed to stand
Chapter 14 established the model: a privileged component observing system calls sees what processes actually do rather than what they claim to do. That remains the architectural basis of the category. The naive picture that goes with it, of a vendor writing a kernel driver and hooking the system call table, is now largely historical, and the correction matters because it explains the direction the whole category is moving.
Platform vendors do not want third parties improvising in the kernel. A defective driver in that position destabilises the machine, and the operating system vendor wears the reputational cost. So each platform now exposes supported interfaces instead, and the security vendor is expected to use them. On Windows, kernel callbacks and Event Tracing for Windows. On macOS, the Endpoint Security framework and system extensions, with kernel extensions deprecated, which Chapter 16 covered. On Linux, extended Berkeley Packet Filter programs and the audit subsystem, which Chapter 17 covered.
The pattern across all three is the same, and it is the fact to carry forward. The platform vendor increasingly mediates what the security vendor may observe. This makes agents more stable and makes their capabilities more predictable, and it puts a ceiling on what any vendor can promise that is set by somebody else.
What an agent actually emits
Concreteness helps here, because 'telemetry' is a word that can mean anything. The event taxonomy is roughly this. Process creation, with the command line, the parent process, the user context and the signing certificate. File events: create, write, rename, delete. Network connections, with destination, port and the process that opened them. Configuration changes, which on Windows means registry writes. Logon events and privilege changes. Module loads. On Windows, the content of executed script blocks.
Two observations about that list. It is very good at relationships over time, which is what detection actually needs: this process launched that one, which wrote this file, which was then read by a process that opened a connection to an unfamiliar address. A single event is rarely interesting; a chain usually is.
And it contains nothing about the content of an encrypted payload, because content is not in the taxonomy at all. The agent records that a connection happened and which program made it. What travelled inside it was encrypted by the browser before the network stack ever saw it.
Detection happens in two places
Some detection runs locally on the agent, and some runs in the cloud over aggregated telemetry from the whole fleet.
Local detection is fast and works offline. It handles the cases where waiting for a round trip would be too late, and where a machine on a hotel network still needs to refuse something known to be bad.
Cloud detection handles everything that needs more than the local machine knows: history longer than the agent keeps, comparison across the fleet, analytics too heavy to run on a laptop, and correlation with signals from other products entirely.
This split explains most of the behaviour a defender notices in practice. Some responses are instantaneous and some take minutes. A device that is off the network still blocks known-bad and still stops generating the correlated alerts that need the fleet view. Neither is a fault; both follow from where the logic runs.
The pipeline, and its economics
Observe, filter, transmit, store, query. Five stages, and the interesting one is the second.
An agent that transmitted everything it could see would saturate the network and produce storage bills nobody would pay. So vendors decide in advance what is worth carrying, and that decision is made once, by the vendor and the organisation's configuration, and applies to every question anybody asks afterwards. Retention is the same kind of decision at the other end of the pipe.
Which yields the constraint that shapes every investigation. A question you did not anticipate can only be answered from data you happened to keep. Not from data that existed at the time; from data that was carried, stored and is still inside the retention window. Chapter 26 develops this at the scale of the whole estate, but it begins here, at the agent, with somebody choosing what not to send.
The pipe runs both ways. Response actions travel down it: isolate a device from the network, stop a process, quarantine a file, push an indicator. The same channel that carries observation carries enforcement, which is why enforcement inherits the pipeline's latency.
The shadow AI lens: the connection, not the conversation
What the agent contributes. Process telemetry surfaces a desktop AI client, and it surfaces a locally run model such as Ollama or LM Studio, together with whatever launched it. Network telemetry surfaces the connection to the AI service with the responsible process attached, which is materially more than a firewall log gives, because it names the program rather than just the machine. The prompt is absent. Chapter 14 already explained why: unless a component sits inside the browser or watches the clipboard, the agent meets the data only after TLS has finished with it.
The agent as an enforcement point, with its caveats stated properly. Custom network indicators let an organisation block or warn on specific addresses, domains and URLs. Network protection is the mechanism that enforces them outside Microsoft's own browsers, and it requires antivirus in active mode with behaviour monitoring and cloud protection enabled. Three caveats belong in any design paper that proposes this, because each of them determines whether the control does what the paper claims.
The first is granularity by browser. Domain blocks work broadly. A block on a specific URL path over HTTPS is matched only in Microsoft Edge; in other browsers the fully qualified domain name is the finest available unit (high). If the intent is to block one part of a site and leave the rest usable, that intent is achievable in one browser and not the others.
The second is that blocking domains in non-Microsoft browsers depends on the browser not hiding the destination. Network protection determines the domain for an HTTPS connection by reading the TLS handshake, which requires the connection to use TCP rather than QUIC and requires the initial handshake message not to be encrypted. Microsoft's documentation says so directly and points to the specific Chrome and Firefox policies to disable QUIC and Encrypted Client Hello (high). Chapter 5's discussion of Encrypted Client Hello and Chapter 4's discussion of QUIC arrive here as an operational dependency: the block works because the browser is configured to let it work.
The third is time. An indicator can take up to 48 hours to reach a device, though Microsoft states that in most cases it is under two (high). A control with a two-hour worst case is a policy instrument, not an incident response instrument.
A correction worth making explicitly. This project's internal source report refers to a generative AI category in Defender for Endpoint web content filtering. Current Microsoft documentation does not support that. Web content filtering's categories are adult content, high bandwidth, legal liability, leisure and uncategorised, with their child categories, and no artificial intelligence category appears among them (high, checked 9 August 2026). An artificial intelligence category does exist in the web content filtering built into Microsoft's Global Secure Access product, which is a different product with a different deployment path (high). Blocking generative AI sites through Defender for Endpoint therefore runs through custom indicators, or through the unsanctioning path of Chapter 24, rather than through a category toggle. This is exactly the kind of drift a manual has to catch, and it is a reminder to re-check category lists rather than inherit them.
The agent as sensor for other systems. Onboarding does double duty. The same act that starts endpoint telemetry makes the device visible to cloud discovery, and, because device onboarding is shared across Microsoft 365 and Defender for Endpoint, it also makes the device available to endpoint data loss prevention and the compliance browser extension (high). Chapter 20 called the onboarded count the number that matters; this is where that becomes concrete, because a single administrative act switches on three chapters' worth of capability.
The reach constraint, restated at this layer. Everything above requires an onboarded device. Directory registration does not produce an agent, adding a work account to Windows does not produce an agent, and enrolling a device in mobile device management does not by itself produce one either (high). Part Three established the ladder; here it becomes the ceiling on Part Four's most capable sensor.
The agent sees the connection, not the conversation, and no licence tier changes that. A vendor claiming otherwise is either describing an in-browser component or describing network interception, and the honest question to ask is which.
Coverage is the onboarded fleet only, which is smaller than the enrolled fleet and much smaller than the registered fleet. Reporting coverage from the wrong number overstates the control by a wide margin.
Enforcement is coarser than it looks on a slide. Path-level blocking in one browser only, dependence on browser configuration for the rest, and a latency measured in hours rather than seconds.
Telemetry costs money and is therefore filtered, and the filter is set before the question is asked. Deciding what to keep is a security decision wearing a finance decision's clothes.
Platform vendors are narrowing what agents may observe. This is good for stability and it means the capability set is not the vendor's alone to determine, and it moves. Directionally clear, specifically unstable (medium).
Locally run models are the awkward case, and increasingly the interesting one. A model running on the machine produces a process, file activity and resource consumption, and no network destination at all. There is nothing for a network control to block. The relevant lever is application control, which Chapter 15 covered, and which lives on the same managed devices as everything else in this chapter.
- Explain to a manager why an endpoint agent with privileged access to a laptop still cannot produce the text of a prompt, without using the word 'encryption' more than once.
- You are writing a design paper proposing to block an AI service at the endpoint. Name the three caveats you would put in it, and say which one a staff member could defeat without any technical knowledge.
- A committee asks what proportion of the fleet an endpoint-based control covers. Which count do you present, and what do you say about the larger numbers somebody else will quote?
- A staff member runs a model locally on a managed laptop. Describe the evidence that leaves, and name the control category that addresses it.
- Name the single design decision that determines whether an investigation eighteen months from now is answerable, and say when that decision is made.
Glossary terms used in this chapter
application control · custom indicator · Defined from earlier chapters and reused here · device isolation · device onboarding · EDR · Encrypted Client Hello · Event Tracing for Windows · kernel · MDE · network protection · QUIC · sensor · SmartScreen · system call · telemetry pipeline · threat hunting · TLS · userland · web content filtering
Sources
Every Microsoft Learn page below was verified against the Microsoft Learn documentation service on 9 August 2026.
- Microsoft Learn, 'Create indicators for IPs and URLs/domains'. learn.microsoft.com The source for the enforcement caveats in this chapter: that Microsoft browsers are handled by SmartScreen and other processes by network protection; that HTTPS URL paths are matched only in Microsoft Edge while fully qualified domain names can be blocked in other browsers; that blocking domains in non-Microsoft browsers requires QUIC and Encrypted Client Hello to be disabled; and that policy can take up to 48 hours to take effect, in most cases under two. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Use network protection to help prevent connections to malicious or suspicious sites'. learn.microsoft.com Supports the description of network protection as the enforcement mechanism for custom indicators, unsanctioned cloud applications and web content filtering outside Microsoft browsers. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Web protection in Microsoft Defender for Endpoint'. learn.microsoft.com Supports the statement that network protection reads the TLS handshake to determine the destination for HTTPS connections, and the up to two hours of latency between an indicator being added and enforced. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Web content filtering in Microsoft Defender for Endpoint'. learn.microsoft.com The source for the correction in this chapter: the full parent and child category list contains adult content, high bandwidth, legal liability, leisure and uncategorised, and no artificial intelligence or generative AI category. Also supports the stated limitation that full URLs are unavailable in third-party browsers, so blocking a web application may require a custom indicator for its sign-in page. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Global Secure Access web content filtering categories'. learn.microsoft.com Supports the existence of an artificial intelligence category in a different Microsoft product's web content filtering. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Onboard Windows devices into Microsoft 365 overview'. learn.microsoft.com Supports the claim that device onboarding is shared across Microsoft 365 and Defender for Endpoint, so a single onboarding act enables endpoint data loss prevention as well. Last checked 9 August 2026; (high).
- Microsoft Learn, 'Onboarding overview' (Microsoft Defender for Endpoint). learn.microsoft.com Supports the claim that onboarding is a distinct administrative act and not a consequence of directory registration or enrolment. Last checked 9 August 2026; (high).
- Apple Developer, Endpoint Security framework. developer.apple.com Cited in Part Three for the supported macOS interface for security agents; reused here for the claim that platforms now mediate observation through supported interfaces. Confirmed to exist by search; not re-read end to end for this chapter. (medium).
- eBPF project documentation. ebpf.io Cited in Chapter 17 for the Linux observation interface; reused here for the same claim. Confirmed to exist by search; not re-read end to end for this chapter. (medium).
- Shadow AI Controls in Microsoft 365 E5, Behaviour by Windows Device State (this project's internal source report). The source of the device-state constraint on endpoint controls. Note that this chapter corrects the report's reference to a generative AI category in Defender for Endpoint web content filtering.
Open questions
The direction of travel on kernel-mode security agents is clear across Windows, macOS and Linux, and the specifics are vendor and version dependent and continue to change. Verify against current platform documentation before quoting particulars (medium).
Microsoft documents indicator propagation as up to 48 hours with most cases under two hours, and separately documents web content filtering policy as up to two hours. These are different mechanisms with different figures, and both should be measured in the tenant rather than quoted from documentation (medium).
Whether any generative AI category will appear in Defender for Endpoint web content filtering in future is not something I can predict. It is present in Global Secure Access web content filtering today and absent from the Defender for Endpoint list (high for the current state, checked 9 August 2026).
Last updated 9 August 2026