AI Session Supervisor Dashboard Control-Plane Abuse

How the attack works

An AI agent process is expected to just run its task and be watched by the dashboard, never to call the dashboard's own API. The detection triggers when that agent sends a state-changing request (like send-keys, attach, kill-session, or approve) to the dashboard's control endpoints, or when it hammers the dashboard's login page over 25 times in 3 minutes, which looks like credential stuffing. If the agent used a control command, the rule also checks for supporting evidence: the agent scanning the same dashboard repeatedly, finding a second dashboard-like host on the internal network, or reaching out to a public internet host shortly after — any of which suggest the agent is exfiltrating session data or receiving outside commands.

Netzilo detection

Why it matters

If successful, an attacker (or a compromised agent) gains the ability to take over other AI agent sessions — reading their output, injecting commands, or killing them — effectively hijacking the oversight mechanism meant to keep AI agents in check.

What you can do

• →Restrict which processes and network paths can reach the session-supervisor dashboard's API and login page; treat it as a sensitive control plane, not a normal internal tool.
• →Rate-limit and alert on repeated authentication attempts against the dashboard, separate from normal user login patterns.
• →Review why an agent process would ever need to call the dashboard's own API, and block that path unless there is a specific, audited reason.
• →When this fires, check whether the traffic matches known benign cases (operator-driven agent shell, health-check polling, or test suites) before treating it as a compromise.

Known benign look-alikes

• An operator or engineer legitimately driving the supervision dashboard from a monitored agent shell (for example asking the agent to restart a wedged tmux session with curl). This produces the mutating-verb anchor and will be reported once per host per 15 minutes.
• Health-check or polling automation running inside an agent process that GETs /api/sessions on a loop. GET alone is never an anchor; it only counts as the enumeration corroboration stage.
• The dashboard's own integration/e2e test suite executed by an agent, which can generate both auth requests and mutating control calls in a burst.
• A single agent that both talks to the internal dashboard and legitimately calls a public API (docs, package registry, model provider) in the same window - the public-egress stage is corroboration only and can never fire on its own.
• Browser-driven dashboard use is normally NOT attributed to a monitored agent process and therefore does not reach the detection at all.

References

• https://github.com/topics/tmux-dashboard
• https://attack.mitre.org/techniques/T1110/
• https://attack.mitre.org/techniques/T1046/