Who Ran That Script? Agentic Automation Is Acting on Your Endpoints — Can You Prove What It Did?

The Accountability Question Just Landed in Your Script Library

For most of enterprise IT's history, accountability was boring — and that was the point. A person logged in. A person had permissions. A person ran the command. When something broke, you worked backward from the username. InfoWorld's recent piece, "When an agent acts, who is accountable?", describes how agentic AI breaks that chain: software no longer just suggests what someone should do — it does it, calling tools, chaining multi-step decisions, and increasingly operating without a human approving each move.

If you run an RMM, you crossed that line a while ago. Scheduled script deployments, auto-remediation policies that fire the moment an alert trips, overnight patch pushes — automation has been taking real actions on your endpoints for years. Agentic AI just turns the dial from "run this script on a schedule" to "decide what needs doing and do it across five systems."

That makes the article's deceptively simple question — when an agent does something, who did it? — deeply practical for IT teams. It's the 2 a.m. page where the first hour isn't spent fixing the problem; it's spent figuring out what happened. And in most shops the honest answer is: you can't fully tell. Not because the logs don't exist, but because they live in four different tools that have never spoken the same language.

The Problem: Your Automation Outran Your Audit Trail

Fragmented logs mean manual correlation. In the typical stack — Ninja or ConnectWise for RMM, a separate monitoring tool, ConnectWise Manage or Autotask for tickets, maybe Auvik for the network — the record of a single incident is smeared across four consoles. The alert lives here, the automation log lives there, the ticket lives somewhere else. Correlating them means a human copying device names and ticket numbers between browser tabs.

Scripts run as service accounts, so the OS can't help you. When your RMM executes a script, Windows sees the RMM's service account — not a human. The event log says "SYSTEM" or "svc_rmm" did it. If three automation policies and two technicians all used the same run-as context last night, your operating system's audit trail is noise, not evidence.

Script results rarely feed back into monitoring. Most RMMs will tell you a script exited with code 0. They won't tell you whether the thing the script was supposed to fix actually got fixed. So the remediation "succeeds," the disk refills with logs two hours later, the alert flaps or stays green, and nobody knows until users start calling.

Agentic AI multiplies all of it. An AI agent that investigates an alert and runs three commands across two systems produces a chain of actions no single log captures. Answering "who did that?" becomes archaeology — with Event Viewer as your shovel.

These gaps exist because of architecture, not laziness. Most "suites" are acquisitions stitched together — a monitoring product that bought an RMM, an RMM that bolted on a helpdesk — with API sync between separate databases. Sync moves records between systems; it doesn't preserve context. And the data models were designed for a world where a human clicked every button.

The 90-Minute Archaeology Session

Monday, 9:14 a.m. FILE02 stops serving shares. The ticket queue lights up. You open the RMM automation log: "ClearTempFiles" ran against 40 endpoints at 2:00 a.m., all exit code 0. The monitoring tool shows D: dropped below 10% free at 1:58 a.m. and "recovered" at 2:04. Helpdesk ticket #4821 was auto-created, worked by the night tech, and closed at 2:20 with "script ran clean." Nobody can tell you what changed between 2:04 and 9:14, or why. Four consoles, four timelines, zero shared context. You spend 90 minutes reconstructing the story before you even touch the server — and the business spends those 90 minutes without file shares.

Multiply that pattern across a month and the damage is concrete:

• MTTR inflation. "What happened?" forensics routinely takes longer than the fix itself.
• SLA reports nobody trusts. The helpdesk says the ticket was resolved in 35 minutes; monitoring shows three hours of user impact. With data in separate systems, you can't defend either number to the client.
• MSP credibility. A client asks "who changed this?" and deserves an answer in two minutes — not a callback tomorrow after someone digs through logs.
• Morale and blame. Without a shared timeline, every incident starts with the day shift and the overnight automation pointing fingers at each other. That's how technician burnout starts.

How AlertMonitor Answers "Who Did It?" on One Screen

The question is hard because actions get logged in five places. AlertMonitor collapses that: monitoring, RMM, helpdesk, patch management, and network mapping share one data model and one timeline per device.

One timeline per device. Open FILE02 and read top to bottom: 1:58 a.m. — alert, D: free space below 10%. 2:01 a.m. — automated remediation "ClearTempFiles" triggered by policy, attributed to the policy, not a person. 2:03 a.m. — script output: 12.4 GB reclaimed. 2:06 a.m. — alert auto-closed with the script output attached as evidence. 9:14 a.m. — alert, Windows Server service failure. 9:16 a.m. — remote session opened by J. Rivera. 9:31 a.m. — ticket resolved and linked to both alerts. The full chain — alert, action, outcome, ticket — exists without anyone copying an ID anywhere.

Attribution is structural, not disciplinary. Automated actions are attributed to the script or policy that ran them. Manual actions are attributed to the named technician — including actions taken inside a remote session. When a client or auditor asks "who did this?", the answer is a filter, not an investigation.

Script results feed back into monitoring data. In AlertMonitor, a remediation isn't "done" when the process exits — it's done when the underlying metric recovers. If ClearTempFiles reclaims space but D: keeps filling, the alert doesn't close; it escalates, with the script output attached. That kills the worst failure mode of fragmented stacks: a green dashboard sitting on top of angry users.

Zero tab-switching. The tech who gets the alert reviews the timeline, runs the script, watches the output, opens a remote session, and updates the ticket — in the same console, in one workflow. Faster resolution and a complete audit trail are side effects of the same design, not two separate chores.

Compare the flows. Fragmented: alert lands in tool A, copy the hostname into RMM tool B, run the script, paste the output into ticket C, and hope someone cross-checks monitoring tool D. AlertMonitor: alert triggers the script, output lands on the alert and the device timeline, metric recovery closes the alert with evidence, ticket links automatically. The 60–90 minute forensics tax becomes about two minutes of reading.

Practical Steps: Make Your Automation Accountable This Week

1. Inventory your automation surface. Export every scheduled script, auto-remediation policy, and patch policy from your current RMM. If that list surprises you, that's the finding — agents are already acting in your environment without a map.

2. Make every remediation script self-documenting. A script that logs its start, scope, and outcome turns any future "who did this?" into a two-minute lookup:

# ClearTempFiles.ps1 - remediation with built-in attribution
$log   = "C:\ProgramData\AlertMonitor\remediation.log"
$stamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

Add-Content $log "$stamp | ACTION=start | SCRIPT=ClearTempFiles | HOST=$env:COMPUTERNAME | TRIGGER=automated-policy"

$before = (Get-PSDrive C).Free
Remove-Item "$env:TEMP\*" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "C:\Windows\Temp\*" -Recurse -Force -ErrorAction SilentlyContinue
$reclaimed = [math]::Round(((Get-PSDrive C).Free - $before) / 1GB, 2)

Add-Content $log "$stamp | ACTION=complete | SCRIPT=ClearTempFiles | RECLAIMED_GB=$reclaimed"
Write-Output "Reclaimed $reclaimed GB on $env:COMPUTERNAME"

When this runs through AlertMonitor, the output lands directly on the device timeline and the triggering alert — nobody has to RDP into a server to read a local log file.

3. Know your real exposure before automation acts. Disk pressure is the classic case where an automated cleanup helps and a blind one hurts. Get the fleet-wide picture first:

$servers = "DC01","FILE02","SQL03","APP05"
Get-CimInstance -ComputerName $servers -ClassName Win32_LogicalDisk -Filter "DriveType=3" |
    Select-Object PSComputerName, DeviceID,
        @{n='SizeGB';e={[math]::Round($_.Size/1GB,1)}},
        @{n='FreeGB';e={[math]::Round($_.FreeSpace/1GB,1)}},
        @{n='FreePct';e={[math]::Round(($_.FreeSpace/$_.Size)*100,1)}} |
    Sort-Object FreePct | Format-Table -AutoSize

In AlertMonitor, this becomes a script in the shared library scoped to a device group — run it from the alert or on a schedule, and the results are stored per device on each machine's timeline.

4. Verify patch state before you blame or credit automation. "Something changed" is very often "something patched." Answer that in seconds:

$last = Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 1
$age  = (New-TimeSpan -Start $last.InstalledOn -End (Get-Date)).Days
[PSCustomObject]@{
    Host      = $env:COMPUTERNAME
    LastKB    = $last.HotFixID
    Installed = $last.InstalledOn
    AgeDays   = $age
    Compliant = ($age -le 30)
}

Because AlertMonitor's patch management shares the platform's data model, this answer doesn't require leaving the incident — the patch history is already sitting on the device timeline between the alert and the failure.

5. Apply the same discipline to Linux servers in the fleet:

for host in web01 db01 app01; do
  echo "=== $host ==="
  ssh "$host" "df -h / | tail -1"
done

6. Wire the loop together in AlertMonitor. The fully accountable automation workflow looks like this: the script lives in the shared library with a clear name and owner; a monitoring alert or a schedule triggers it on a defined device group; output and exit code attach to the alert; if the metric recovers, the alert closes with evidence attached; if it doesn't, the alert escalates to a technician, whose remote session and ticket updates land on the same timeline. Every "who did it?" resolves to a policy name or a person — in seconds, not hours.

The agentic AI accountability question isn't going away; it's getting louder. The teams that will be fine aren't the ones avoiding automation — they're the ones whose tooling can always answer, precisely: what acted, on what, when, and with what result.

Related Resources

AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources