In the first post, we asked the question every SOC is going to be asking soon: did the human do that did the AI or did the human tell the AI to do it?  We argued that EDR is the right place to answer it,  and laid out a five-bucket attribution model.

This is where we run the trace. The model is implemented as six KQL queries against Defender Advanced Hunting, sharing a common preamble that defines lookup lists, identifies high-confidence Cowork “seeds,” walks the process tree, and brackets out AI activity windows for mediated-attribution joins. We’ll go through each query in order — what it does, why the joins are shaped the way they are, where the weights come from, and what to tune before pointing it at production.

Attribution Model Refresher

The scoring rubric

The model is additive. Every query collects signals and assigns points; the total is capped at 100, run through a noise suppressor, and bucketed. Here’s the full rubric.

Tier 1 — Direct AI seed evidence (cmdline / process)

Tier 2 — Process lineage (descendants of a seed))

Tier 3 — Temporal proximity to a seed

Tier 4 — AI-mediated heuristics (the GUI computer-use case)

Tier 5 — Network corroboration

Tier 6 — Indirect / weird worker hints

Tier 7 — Suspicious child behavior (PowerShell-specific)

Noise suppressors (negative scores)

Final classification

RawScore = sum(all tiers) + sum(noise suppressors)
Score    = clamp(RawScore, 0, 100)

Attribution = case(
    Score >= 90, "Direct AI — local",
    Score >= 80 and HasNetworkSignal, "Direct AI — network",
    Score >= 50, "AI-mediated",
    Score >= 30, "Weak / review",
    "Background"
)

A few notes on the design choices. The Tier 1 weights are tuned so that any single strong signal, claude.exe plus an MCP cmdline keyword, for example, is enough to reach a “Direct AI” verdict on its own. That keeps the most obvious cases easy. The mediated tiers are deliberately weaker so that a coincidence (a human happens to open the same file Claude read 20 minutes ago) doesn’t get auto-labeled as AI activity. And the noise suppressors are aggressive, -60 for known noisy processes and -50 for session 0, because in our testing the false positive rate without them was ugly.

The queries

The model is implemented as a set of KQL queries against Defender Advanced Hunting. They share a common preamble that defines all the lookup lists, identifies “seeds” (high-confidence Cowork processes), walks the process tree, and brackets out AI activity windows. Paste the preamble at the top of each query.

Shared preamble — paste at the top of every query

Query 1 — Direct AI seed detection

This is the simplest of the queries and the entry point for any investigation. It surfaces clear Cowork-attributable activity and is your “is AI even running on this host” question, answered.

Query 2 — Process tree visualization (0–3 hops from seed)

Use this when you need to see exactly what a Cowork session spawned. This is the query you run after Query 1 lights up, it gives you the full picture of children, grandchildren, and great-grandchildren, with the seed cmdline carried along for context.

Query 3 — Score file events with full attribution

This is the operational workhorse. It scores every file event (read, write, create, move) and outputs an attribution category. This is the query you’d schedule, alert on the high-scoring rows, and feed into the rest of your investigation tooling.

Query 4 — Score process executions

Same scoring philosophy as Query 3, but applied to DeviceProcessEvents. This catches AI-driven app opens, shell invocations, and suspicious child processes, the place where you find PowerShell launched by Claude with -enc and start asking pointed questions.

Query 5 — Network corroboration with destination categorization

Adds the “Direct AI - network” verdict and supports “AI-mediated network” attribution. Useful for spotting data leaving the host through an AI-driven Word or Edge session that talks to a vendor cloud right after Claude has been at the wheel.

Query 6 — Unified timeline (the SOC view)

Combines file, process, and network attributions into one chronological view. This is what an analyst opens during an investigation to answer the only question that really matters: what did the AI do, in order?

Operational notes

When to trust each bucket

• Direct AI - local / network is high enough confidence to alert, log, or auto-tag in your SOAR. Worth surfacing to the SOC immediately.
• AI-mediated should not auto-alert; surface it during investigations. This is the bucket where you say “the user appears to have used Cowork to do X.”
• Weak / review stays in a queue. It’s useful for tuning the model but shouldn’t notify anyone.
• Background is suppressed.

Tuning before production

A few things to fix before you point this at your tenant in anger.

1. Replace the folder-scope matching keywords (Documents\Claude\Scheduled, etc.) with whatever business folders matter in your environment and are configured for Cowork to use.
2. Confirm the Cowork cmdline keywords are still current. Anthropic ships new MCP servers and feature flags, and this list will drift over time. Re-baseline it quarterly against fresh telemetry.
3. Validate that InitiatingProcessUniqueId is populated in your tenant. If it isn’t, fall back to InitiatingProcessId plus InitiatingProcessCreationTime as a composite key — PID alone is unsafe.
4. Move the cmdline keywords, install paths, and publishers to a Sentinel watchlist if you have it. Updates shouldn’t require query edits.
5. If you rely on DNS-only network telemetry, add a DnsConnectionInspected host extraction. The current network query handles SNI and RemoteUrl but not DNS-only environments.

Known limitations

Defender alone cannot always definitively prove “this was AI, not a human” for GUI-driven actions. The mediated-activity scoring is probabilistic, not deterministic. A real human could open a file Claude previously read, in the same session, within 30 minutes, and the model will (correctly) grade that as “AI-mediated” rather than “Direct AI.” That’s not a bug; that’s the model being honest.

A few other things to be aware of. Multiple concurrent AI sessions on one host can confuse the temporal join; if you see this, key the joins on SeedProcUid instead of just DeviceId + SeedTime. Cowork running inside WSL2 or Hyper-V will show up as vmwp.exe activity, which the model gives partial credit (+20) for, but you’ll need to enable WSL guest telemetry collection to see what’s actually happening inside the VM. And of course this is Claude-specific, the same approach works for OpenClaw, and others, but the seed signals (process names, cmdline keywords, vendor domains) are different and need their own list.

Wrap-Up

The above queries are designed to help you better understand what is happening in your environment right now. While these AI solutions can be really help for productivity and efficiency, the have opened up an Action Provenance problem, as AI takes on the persona of an individual and starts performing tasks on their behalf.

More logging, and understanding will be required to help with attribution in the future, but we can’t wait, and this blog series is designed to help you get started right now on a problem you may not have known was just introduced into your environment!

As always, if you need assistance SRA is here to help!