In a data-loss deployment, what can an inline endpoint or mail-path control prevent that an API-based SaaS scanner cannot?

## Placement decides capability The most useful way to read a data-loss architecture is not by which vendor is in it but by **where each component sits relative to the action it cares about**. That single fact decides whether the control can prevent anything, how quickly it speaks, and which channels it is simply blind to. ### Inline: in the path, holding the action An **endpoint agent** hooks the operating system and the applications on the device. When a file is written to removable media, sent to a printer, pasted into a browser upload, or handed to a sync client, the agent gets the content at that moment and returns a verdict before the operation completes. Because it inspects inside the application, the content is available to it in the clear regardless of how the channel is later protected on its way out. The **outbound mail path** is inline in the same sense: the message is held while policy evaluates, so the possible actions are real interventions - drop, hold for review, strip the attachment, force encryption, warn the sender, add an approver. Properties that follow: - **Prevention is possible.** A block means the bytes did not go. - **The user finds out immediately.** Interruption is the point, and it is also the cost. - **Coverage equals installation.** Only managed devices with a healthy agent are covered, and only the channels the agent hooks. - **Latency is a user-visible budget.** Inspection has to finish in the time a person will tolerate, which caps how much content can be examined and how deep the inspection can go on a very large file. ### Out of band: attached to the tenant over its API A **SaaS API scanner** authorises against the tenant - a collaboration suite, a file-sharing service, a CRM - and enumerates or subscribes to changes. It sees a file after it has been uploaded, and a share after it has been created. Detection lag ranges from near-real-time on a change feed to hours on a full crawl. Properties that follow: - **It cannot prevent.** Everything it reports has already happened. Its response verbs are remedial: revoke an external link, remove a collaborator, move the file to a quarantine location, notify the owner, apply a label. - **Device coverage is irrelevant.** A file uploaded from an unmanaged home laptop lands in the tenant like any other and is inspected identically - the one place where the agent has no answer. - **It reaches backwards.** A new policy can be run over the entire existing corpus, which is how you discover the customer list that has been shared with a link since 2023. No inline control can do this; inline only ever sees new events. - **It is blind off-tenant.** A USB copy, a print, a screenshot, or a sync client uploading a folder to a personal cloud account never appears in the corporate tenant's API, so the scanner has no record that any of it happened. ### Monitor versus block is a second, independent axis Inline placement makes blocking *possible*; it does not make it wise. Most deployments run a new policy in monitor first precisely to find out how much legitimate work it would have stopped, because at a company where sales and marketing move customer data every day, a confident-looking rule can turn out to fire mostly on people doing their jobs. A middle setting exists on many inline controls: block but let the user override with a stated business justification. That keeps the friction and the prevention while producing something an analyst can read - a human sentence attached to the incident - and it converts a hard stop into a signal. ### What this means when the alert lands The placement changes the first move on the incident, and interviewers probe exactly this. | | Inline block | API scanner finding | |---|---|---| | Did the data move? | No, on this path | Yes, already | | First question | Was this legitimate? | Who could reach it, and for how long? | | Investigation posture | Subject already knows | Subject may not know yet | | Next risk | They retry on a channel you do not cover | Copies already made downstream | An inline block has spent your covertness: the person has seen a dialog. If the block was wrong, you have interrupted somebody's deadline; if it was right, you have told a motivated person exactly which channel is watched, and the next attempt may go to a channel that is not. A scanner finding costs nothing in covertness but starts the clock late - the useful work is establishing the exposure window from the tenant's own access records and then remediating. A serious deployment therefore runs both, and the honest description of why is not defence in depth as a slogan: it is that neither one can see the other's channels, and only one of them can say no.