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 remediated or superseded 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.

Suppressed is the exception, and it is deliberate. Suppression exists to silence a finding you have judged to be noise, so a suppressed finding does not re-raise when the detector observes the same condition again — that is the whole point of it. Because of that, always prefer a time-boxed suppression: the Suppress dialog defaults to 30 days and un-suppresses automatically when the window closes, which forces the judgement to be re-made rather than standing forever. Choose Indefinitely only when the condition is genuinely permanent and accepted. A suppressed finding stays visible under the Suppressed state filter and can be returned to the queue at any time with Reopen.

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.

DMARC aggregate reports

The DLP & DMARC page pairs the Purview DLP activity above with your domains' DMARC aggregate (rua) reports — the daily XML summaries that receiving mail providers send back, telling you which senders are using your domain and whether their mail passed SPF and DKIM. It is how you find out that a legitimate marketing platform is failing alignment before you tighten your policy to p=reject and start losing real mail, and how you spot someone spoofing your domain outright.

How reports reach TATER

DMARC reports are not something TATER can go and fetch: providers push them by email to whatever address your DNS record's rua= tag names. So the flow is:

1. Publish a rua address in DNS. Your _dmarc.<domain> TXT record must include rua=mailto:<address>. Reports begin arriving within a day or two; each provider sends roughly one per day per domain.
2. Point an email-intake integration at that mailbox with intakeType='dmarc'. Every aggregate report is parsed as it arrives — reports are usually gzip- or zip-compressed XML attachments, which the intake unpacks for you.
3. Read the results on the DLP & DMARC page, or via the get_dmarc_summary MCP tool, which aggregates per domain: message volume, SPF and DKIM pass rates, and the sending sources seen.

The mailbox is usually not the one you expect. Organisations very often route rua to a dedicated address (dmarc@…) rather than to an admin alias, precisely so that a few dozen machine-generated XML mails a day do not land in a person's inbox. Point the intake at the mailbox the DNS record actually names — check the live TXT record rather than assuming — or the integration will sit healthy and idle while every report goes somewhere TATER never reads.

Reading the numbers

A DMARC report describes mail claiming to be from your domain, which is not the same as mail you sent. Two habits keep the interpretation honest:

• Judge alignment per sending source, not in aggregate. A 92% overall pass rate can be one high-volume service failing completely while everything else is perfect — that service is the thing to fix, and the aggregate hides it.
• A failing source is not automatically an attacker. Newly-onboarded SaaS senders, ticketing systems and payroll platforms fail alignment constantly because nobody added them to SPF or set up DKIM. Identify the source before treating it as abuse.

Very large reports are truncated at an internal row cap; when that happens the parsed record says so rather than silently presenting a partial picture as complete.

Signal health

Both sources on this page report their own health, and the distinction matters: "no findings" and "not collecting" look identical on a dashboard. A DMARC source that has never ingested a report means nobody has wired the mailbox — not that your domains are clean. Check the signal-health state before drawing any conclusion from an empty view.

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.