Application Monitoring

What it does

Application Monitoring (TATER Manage → Endpoint Health → Application Monitoring) is the home for noisy, continuously-detected fleet signals. Instead of auto-filing thousands of help-desk tickets, every detection is kept as a deduplicated finding - a continuously-updated state you acknowledge, suppress, resolve, or explicitly promote to an Ops task when it genuinely needs help-desk lifecycle. The same findings queue is also available to technicians in TATER Ops → Workspace → App Monitoring; monitor definitions (create/toggle) are managed in TATER Manage.

It has two layers:

• Findings - "what we found", deduped on (org, source, device, resource). Repeat detections increment an occurrence count instead of creating duplicates.
• Monitors - "what to watch". Built-in monitors plus templated monitors you create and toggle on/off.

Findings - sources & lifecycle

Findings carry a severity, a source, the affected device, and a lifecycle state. Sources include:

Lifecycle: open → acknowledged → suppressed → remediated → superseded. A finding auto-reopens if the signal returns, and auto-clears (remediated) when the detector or agent reports the condition resolved. Findings have a 180-day TTL.

Built-in monitors

Two monitors are always present, seeded per organization. They are toggle-only (you can turn them off, but not delete them):

• OneDrive Sync Health - see the OneDrive Sync Health guide. Confirmed-degraded devices raise an onedrive finding. Turning this off stops new OneDrive findings.
• CISA KEV Exposure - per-device installed software correlated against the CISA KEV catalog. Turning this off stops new kev findings.

Templated monitors

Create monitors from the Monitors tab → + Create Monitor. The TATER agent (v2.4.17+) evaluates each enabled monitor on its targeted devices every 15 minutes and reports pass/fail, which raises or clears a monitor finding.

Custom-script bodies must be ASCII-only - non-ASCII characters corrupt the temp file the agent writes for evaluation.

Scan freshness (stale data alerts)

Scan-derived views render whatever was last captured, with no live re-check - so a capture that has quietly fallen weeks behind reads on screen exactly like current data. TATER tracks each scan source against a cadence SLA and raises a monitoring finding (source scan-freshness) when a source goes stale or has never run, so nobody has to notice on their own.

Aging does not alert. It is the headroom state - one missed cycle, still within tolerance - and paging on it would train people to ignore the signal. Only Stale and Never run raise a finding. Stale carries the higher severity of the two: never-run is a setup gap where there is simply nothing to trust yet, while stale actively misleads, because the data is on screen looking current.

Findings auto-resolve: when a source comes back inside its SLA the finding is remediated automatically, so fixing the scan clears the alert without anyone closing it by hand. The sweep runs every 6 hours, comfortably inside the tightest (4-day) window.

Identity / NHI is tracked separately on purpose. It is refreshed by the cloud scan, so it can silently fall behind while the cloud source itself still looks fresh - which is exactly how an Identity Security view kept showing app registrations that had already been remediated. Watching the parent scan alone would not have caught it.

You can also pull the same picture on demand at any time from GET /api/scan-source-health, which returns each source's state, capture timestamp, age, record count, last job status, and a plain-language diagnosis with the command to refresh it.

Microsoft Purview DLP alerts

TATER can ingest Microsoft Purview Data Loss Prevention (DLP) alert activity as monitoring findings (source purview-dlp), one aggregate finding per DLP policy. This gives continuous visibility into DLP health - and in particular catches the case where a rule's "Send an alert to admins" (GenerateAlert) setting was silently turned off: alert volume for that policy drops to zero, which surfaces here as a finding to review. Maps to CISA SCuBA 4.3 / 4.4 continuous-DLP-evidence expectations.

Setup

1. Grant the Graph permission (customer tenant, Entra admin). On the app registration you use for TATER cloud scanning (the app whose Client ID + Secret are stored as this org's tenant credential under Settings → Tenants): add the Microsoft Graph application permission SecurityAlert.Read.All and grant admin consent. This is the exact least-privilege permission the Graph /security/alerts_v2 API requires - it is read-only and does not grant access to DLP content. No new app or secret is needed.
2. Confirm the DLP policies actually alert (Purview admin). In the Purview portal → Data loss prevention → Policies, make sure each relevant rule has "Send an alert to admins" (GenerateAlert) enabled. From then on, a drop to zero alerts on a previously-active policy is itself surfaced as a finding.
3. Enable it in TATER (Admin). POST /api/monitoring/dlp/config with { "enabled": true, "targetTenantId": "<your M365 tenant GUID>", "windowDays": 30 } - or ask the AI Analyst to run ingest_purview_dlp({ target_tenant_id, window_days }) to configure-and-run in one step. A daily sweep then keeps it fresh; you can also run POST /api/monitoring/dlp/ingest on demand.
4. Verify. The ingest returns { policies, alerts, findings } - a nonzero alerts confirms Graph access works. The per-policy findings then appear on this page filtered to source Purview DLP.

Detecting a disabled GenerateAlert flag directly (rather than inferring it from zero alert volume) requires reading the DLP rule configuration via Security & Compliance PowerShell - a separate build. This feature detects it via the alert-volume signal, which needs only the read-only Graph permission above.

The page

• Counts at the top (Open, KEV Exposure, SLA Breached, Due Soon, Acknowledged, Suppressed, Total) come from the live findings summary.
• Findings tab - every source as a row with severity/source pills, SLA badge, occurrence count, and per-finding actions: Ack, Suppress, Resolve, and To Task (promote to a TATER Ops task with full evidence). Filter by source, state, severity, and search.
• Monitors tab - every monitor with an ON/OFF toggle, plus Create Monitor (templated) and edit/delete for the ones you create.

Promote to an Ops task

Most findings should stay on the monitoring surface. When one genuinely needs help-desk lifecycle (assignment, SLA, comments), click To Task - it creates a linked TATER Ops task pre-filled with the finding evidence, priority derived from severity, and a back-link. Only do this when you want a person to own it.

Permissions

Auditor+ can view findings and monitors. Admin+ can acknowledge / suppress / resolve / promote findings, and create / edit / delete / toggle monitors.

MCP tools

Available on both the HTTP and stdio MCP servers:

• list_monitoring_findings, get_monitoring_summary, acknowledge_monitoring_finding - the findings surface.
• list_monitors - list monitor definitions and their on/off state.
• create_monitor - create a templated monitor (Admin).
• toggle_monitor - enable/disable a monitor by id (Admin).
• ingest_purview_dlp - pull Purview DLP alert activity and upsert per-policy aggregate findings (Admin; metadata only). See Microsoft Purview DLP alerts.

Activating templated monitors on the fleet

Built-in monitors (OneDrive, KEV) work immediately. Templated monitors require agent v2.4.17+ - the agent auto-updates at next restart (or push a fleet restart wave). Once updated, agents pick up enabled monitors within ~15 minutes.