A Prompt Asked AWS AgentCore for Its Credentials — and It Complied. Your RMM Agents Have the Same Privileges

What Just Happened

Security researchers picked apart AWS AgentCore — the platform Amazon is pitching to enterprises for building autonomous AI agents — and found the security model comes apart with something embarrassingly simple: a prompt that asks the agent for its credentials. Per The Register's reporting, tokens get transmitted in metadata where injected instructions can reach them, the VM isolation between agent sessions is weaker than you'd assume, and the default permissions are expansive enough that a stolen token actually opens doors.

Read that twice if you run infrastructure for a living — not because you're deploying AgentCore next quarter, but because the failure mode is one you already operate at scale.

Every RMM agent sitting on every workstation and server you manage is an autonomous instruction executor. It polls for commands, runs whatever code it receives, and does it as SYSTEM with access to whatever credentials live on that machine: service accounts, scheduled task passwords, cached tokens, whatever the last admin saved. Your RMM doesn't need a prompt injection to be talked into running the wrong code. It needs someone to compromise the console that talks to it, or the credentials that unlock it.

The AgentCore disclosure is the loudest recent reminder that the agent did what it was told is not a security posture. For IT teams and MSPs, the question isn't whether your automation can be abused. It's whether you'd know, how fast you'd find out, and how much it would cost.

The Problem: Standing Superusers With a Blind Spot

Your RMM holds the keys to everything, by design

The Kaseya VSA incident in July 2021 is still the canonical example. Attackers didn't breach 1,500 downstream businesses one at a time — they compromised one RMM platform and pushed ransomware through the same deployment mechanism MSPs use to push fixes. Downtime was measured in days, some victims stayed offline for a week or more over a holiday weekend, and incident responders had to reconstruct what happened from fragmented logs scattered across the MSP stack.

That's the structural issue with traditional RMM tooling: it was engineered as a force multiplier first and an auditable system second. A technician account that can run a script against all endpoints usually can do it with minimal friction, and the record of what ran is buried in per-device logs nobody correlates until something is already on fire.

Credentials multiply across every tool you bolt on

Count the places your admin credentials exist right now. The RMM credential vault. The monitoring platform's stored credentials for checks. The PSA integration that syncs tickets. The password manager your techs actually use. Browser sessions that stay logged in for weeks. Every integration copies secrets, every copy is another rotation job, and during an incident, every copy is another place to check for leakage.

This is where siloed architecture stops being an inconvenience and becomes a liability. When monitoring, RMM, helpdesk, and patching live in separate products, each one holds its own credential store, keeps its own activity log, and knows nothing about the others. Nobody can answer — from one place — the question that matters after any suspicious event: what privileged actions ran across this environment, when, and what triggered them?

What it actually costs

Walk through a realistic scenario. A tech at a 12-client MSP gets phished; the attacker lands in the RMM console. They don't touch 300 endpoints individually — one script pushed to a device group dumps credentials or worse. Your IR firm asks for a timeline of script executions. With fragmented tooling, that timeline gets reconstructed from four consoles, CSV exports, and one tech's memory of which tickets were open. Days of billable forensics. A client trust problem. A cyber insurance renewal you now fill out differently than last year.

Even without a breach, the sprawl taxes you daily: the tech with five tabs open to work one ticket, the alert in the monitoring tool whose fix runs in the RMM and whose documentation lives in a helpdesk neither tool updates, the SLA report nobody trusts because response data and resolution data come from systems that don't talk to each other. Technician burnout in ops teams is rarely about ticket count alone — it's the friction tax on every single ticket.

How AlertMonitor Changes the Equation

AlertMonitor's answer is architectural, not additive: infrastructure monitoring, RMM, helpdesk, network topology, and patch management in one platform — one credential surface, one activity timeline.

One platform, fewer credential copies. When the technician who gets the 2 a.m. disk-space alert opens the device directly from the alert and launches a remote session or pushes a fix from the same screen, you eliminate the separate RMM console with its own login, its own vault, and its own sync integrations. Fewer stores means fewer rotations and a smaller surface for exactly the class of credential theft AgentCore demonstrated.

Every action lands on one timeline. Script results feed back into the monitoring data, and automated remediations and manual technician actions both appear in the same record as the alerts and tickets they relate to. When a client security questionnaire or your IR firm asks what ran on FIN-APP-01 last Tuesday night, that's one search — not an afternoon of cross-referencing exports from tools that don't share a database.

Scoped fleet actions with captured results. Run scripts across device groups, push software, and open remote sessions — scoped to the clients and groups each technician is responsible for, with output stored centrally against the run. A script that audits service accounts across 40 servers produces results that live in the platform: timestamped, attributable, reviewable.

Alert-to-resolution collapses. The loop becomes: alert fires, device context is already attached, technician or automation runs the fix, output lands next to the alert, and the ticket updates from the same activity. That's the difference between a 40-minute swivel-chair investigation and a five-minute fix, multiplied across hundreds of tickets a month.

To be clear about what this does and doesn't do: no platform makes credential abuse impossible. AWS has one of the best security teams on the planet, and a well-crafted sentence still walked the keys out the door. What a unified platform does is shrink the blast radius and make the trail readable — the difference between an incident you contain in an hour and an outage that defines your quarter.

Practical Steps: Run These This Week

1. Inventory services running under stored credentials. Every service listed runs with a named account whose password lives somewhere on disk or in AD. You need to know how many of these exist in your estate:

Get-CimInstance Win32_Service |
    Where-Object { $_.StartName -and $_.StartName -notmatch 'LocalSystem|LocalService|NetworkService' } |
    Select-Object Name, DisplayName, StartName, State, PathName |
    Sort-Object StartName | Format-Table -AutoSize

Paste it into AlertMonitor's script runner, target your server device groups, and schedule it monthly. The output lands in the monitoring timeline, so you build a running inventory instead of a one-off snapshot.

2. Find scheduled tasks configured with stored passwords. These persist credentials across reboots and are the classic slow-burn exposure:

Get-ScheduledTask |
    Where-Object { $_.Principal.LogonType -eq 'Password' } |
    ForEach-Object {
        [PSCustomObject]@{
            Task    = "$($_.TaskPath)$($_.TaskName)"
            RunAs   = $_.Principal.UserId
            State   = $_.State
            LastRun = (Get-ScheduledTaskInfo -TaskName $_.TaskName -TaskPath $_.TaskPath).LastRunTime
        }
    }

Anything here running as a domain admin deserves immediate attention — dedicated service accounts, not admin accounts, should carry these workloads.

3. Audit local Administrators membership across the fleet. Standing local admin is where credential theft turns into endpoint control:

$servers = Get-Content C:\Temp\servers.txt
Invoke-Command -ComputerName $servers -ScriptBlock {
    Get-LocalGroupMember -Group 'Administrators' |
        Select-Object @{N='Server';E={$env:COMPUTERNAME}}, Name, PrincipalSource
} | Export-Csv C:\Temp\local-admins-audit.csv -NoTypeInformation

In AlertMonitor, this runs against a device group with no jump host required, and the CSV output stays attached to the run in the platform.

4. Do the same exercise for your Linux estate:

# systemd units running under non-root accounts
grep -H '^\s*User=' /etc/systemd/system/*.service /lib/systemd/system/*.service 2>/dev/null | grep -v 'User=root'

5. Then fix the architecture around the findings:

• Scope technician accounts to the clients and device groups they actually support. Retire the everyone-is-admin-everywhere model.
• Consolidate credential storage. Every tool holding a copy of your client admin passwords is another rotation job and another breach surface.
• Treat automation like staff: know which scripts run unattended, what triggers them, and where their output goes. If you can't enumerate that in five minutes, that's your first finding.

The Takeaway

A platform built by AWS, hardened by one of the best security teams in the industry, was undone by a prompt asking nicely for credentials — because the tokens were in reach, the isolation was thin, and the permissions were broad. Swap prompt for phished technician login and you have the exact risk profile of a traditional RMM deployment running on siloed tooling.

You can't guarantee that no instruction-executing system — AI agent or RMM agent — ever gets told to do something it shouldn't. You can control how many places the credentials live, how broad the standing privileges are, and whether one search answers what ran, where, and why. That's the practical case for running monitoring, RMM, helpdesk, and patching from one platform — and it's why AlertMonitor customers spend less time reconstructing history and more time closing tickets.

Related Resources

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