The Register reported this week that OpenAI dismissed three employees — two safety researchers and a program manager — over alleged information misuse, while the company insists the move wasn't retaliation for raising concerns. Whatever the full story turns out to be, the shape of the incident should feel familiar to anyone running IT: an allegation about who accessed what information, a dispute over motive, and a fast-moving situation where the only thing that settles it is evidence.

Now ask yourself the practitioner's version of that question. A client calls and says files on the accounting share were modified over the weekend. HR wants to know whether a departing tech opened a specific workstation. An auditor asks you to produce a record of every remote session and script that ran against your domain controllers last quarter. If your answer involves opening TeamViewer's connection history, your RMM's activity log, your helpdesk, and a spreadsheet to correlate timestamps — you don't have an audit trail. You have an archaeology project.

The Problem: Your Evidence Lives in Five Places That Don't Talk

Walk through what a typical mid-size IT team or MSP is actually running:

• Monitoring — PRTG, Zabbix, or SolarWinds. It saw the disk spike and the service restart. It has its own database and its own clock.
• RMM agent — NinjaOne, Datto RMM, or Syncro. Scripts ran through it. Its activity log records that a script executed, but often not what the script actually output.
• Remote access — ScreenConnect (ConnectWise Control), TeamViewer, AnyDesk, plus plain RDP. Session history lives here. Some tools can record sessions; most teams never switch it on.
• Helpdesk — HaloPSA, ConnectWise Manage, Freshdesk, or (be honest) a shared Outlook inbox. The ticket says someone worked on the file server Tuesday.
• The humans — and here's the killer: at plenty of shops, three technicians share one admin account in the remote access tool, because per-seat licensing was expensive and nobody revisited the decision.

Each tool logs its own slice of reality. None of them record the actor, the action, the target, and the outcome in one place. So when the question comes — and it always comes — you're manually stitching together four logs with different time zones and no shared identifier.

What that looks like in real life

Scenario 1: The weekend change nobody claims. Monday, 8:40 a.m. Accounting can't open files on FS01 — share permissions changed sometime Saturday. Ticketing system: nothing logged for FS01 over the weekend. RMM activity log: one script execution, no captured output, attributed to the shared service account. Remote access tool: two sessions, no recordings. Monitoring: a service restart at 2:14 a.m. that nobody can explain. Three hours later you have four fragments and no answer — and accounting's manager is now in your IT director's inbox.

Scenario 2: The departing technician. A tech gives notice. A week later, someone alleges they pulled data before leaving. If your remote access tool has per-user logins, you can at least show their sessions. If they used the shared account — like at half the MSPs out there — you can't attribute a single action to them, which also means you can't clear them. Innocent people stay under a cloud, and guilty ones hide in the crowd.

Scenario 3: The client audit. A client pursuing SOC 2 or ISO 27001 asks for evidence of who accessed their environment and what changed. With split tooling, that request becomes a week of CSV exports. With shared accounts, it becomes an honest admission that damages the relationship.

This gap exists for unglamorous reasons: monitoring platforms grew up separate from service desks; RMM vendors bolted remote access on rather than building it in; scripts were treated as throwaway utilities, so nobody captured their output; and shared admin accounts were a licensing decision nobody revisited. The result isn't just slower investigations. It's SLA disputes you can't defend, compliance answers you can't give, technician morale poisoned by unresolvable suspicion, and — in the worst case — an allegation like the one in the OpenAI story that gets decided by whoever tells the better story, because nobody has records.

How AlertMonitor Closes the Gap

AlertMonitor was built as one platform — infrastructure monitoring, RMM, helpdesk, patch management, and network topology in the same system — and that architecture changes what an audit trail even is.

Every action lands on one timeline. When a technician opens a remote session, runs a script, pushes software, or approves a patch on a device, it's recorded against that device with the actor, the timestamp, and — critically for scripts — the actual output. The 2:14 a.m. service restart isn't a mystery in a monitoring graph; it's a line item sitting right next to the script that caused it and the technician who ran it.

Script results feed back into monitoring data. Automated remediations and manual fixes appear in the same timeline as the alerts that triggered them. When someone asks why a setting changed, you don't correlate four tools — you filter one device's history.

Per-technician identities by default. Every action is attributable to a named person. For MSPs, role-based scoping means techs only see the clients they're assigned to, so answering client A's questions never requires exposing client B's data.

The workflow, concretely:

• Old way: Alert fires in the monitor → remote session in ScreenConnect → fix applied → ticket updated in HaloPSA → script logged in the RMM with no output → four systems, four exports, three hours of correlation when a question surfaces weeks later.
• AlertMonitor way: Alert fires → technician opens the remote session directly from the alert → runs the remediation script from the same console → output stored on the device timeline → ticket auto-linked. When the question comes later, you open the device, filter the timeline, and read the answer. Two minutes.

For a team managing a few hundred endpoints, that's the difference between answering an access question before lunch and losing a week to it. For an MSP, it's the difference between "let me get back to you" and showing the client a clean, attributable record in the next QBR.

What You Can Do Today

You don't have to wait for a platform migration to tighten this up. Here's where to start.

1. Stop sharing admin accounts. Today. Per-technician logins in your remote access and RMM tools are the single highest-leverage change you can make. If actions can't be attributed to people, nothing else matters.

2. Map who actually has the keys. Most access investigations stall because nobody knows the real access map. Pull local administrator membership and RDP status across your Windows fleet:

# List local Administrators on a remote machine
Invoke-Command -ComputerName FS01 -ScriptBlock {
    Get-LocalGroupMember -Group 'Administrators' |
        Select-Object Name, PrincipalSource
}

powershell

Is RDP even enabled? (0 = enabled, 1 = disabled)

Invoke-Command -ComputerName FS01 -ScriptBlock { (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server').fDenyTSConnections }

3. Know what remote sessions already happened. Windows logs every RDP logon locally — you can pull that history right now, before buying or changing anything:

# Recent RDP logons on a server: who, when, from where
Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-LocalSessionManager/Operational' -MaxEvents 50 |
    Where-Object { $_.Id -eq 21 } |
    Select-Object TimeCreated,
        @{n='User';e={ $_.Properties[0].Value }},
        @{n='SourceAddress';e={ $_.Properties[1].Value }} |
    Format-Table -AutoSize

On Linux boxes, SSH history is in the journal:

# Successful SSH logins from the last 7 days
journalctl -u sshd --since "7 days ago" | grep "Accepted" | tail -20

4. Make your scripts leave evidence. Any script you run through remote management should echo what it did. A service check that logs its own outcome is worth ten silent ones:

# Verify critical services and report the outcome
$services = 'Spooler','wuauserv'
$report = foreach ($name in $services) {
    $svc = Get-Service -Name $name -ErrorAction SilentlyContinue
    if ($svc -and $svc.Status -ne 'Running') {
        Start-Service -Name $name
        "$((Get-Date).ToString('s')) | $env:COMPUTERNAME | restarted $name"
    } else {
        "$((Get-Date).ToString('s')) | $env:COMPUTERNAME | $name is $($svc.Status)"
    }
}
$report

5. Run it centrally and keep the results. In AlertMonitor, you'd push that service check as a script across a device group, and every result — per machine, per technician, per run — lands on the device timeline alongside the monitoring data and the linked ticket. Do the same with the admin-membership audit: schedule it monthly, and drift (a new name appearing in Administrators) becomes a visible change in the timeline, not a Monday-morning surprise.

The Bottom Line

The OpenAI story is a reminder that access disputes don't get settled by intentions — they get settled by records. Your technicians take hundreds of remote actions a week across your estate. If those actions live in five disconnected logs, or worse, behind a shared account, every future question about access becomes a fight you can't prove. Consolidate the stack, attribute every action to a person, capture what every script actually did. The next time someone asks "who touched that server," the answer should be a filter, not an investigation.

Related Resources

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