AI Agent Monitoring: How to Detect Rogue AI Agents

Last verified on Nov 8, 2026.

An agent is a loop: a model reads input, picks a tool, runs it, reads the result and picks again. That loop is useful because nobody scripted each step, and it is risky for the same reason. A rogue agent is one that takes actions outside the scope you meant it to have. Maybe it called an admin endpoint it never needed, ran far longer than any normal task or touched data for the wrong user.

OWASP names this weakness Excessive Agency. Its triggers include model hallucination and prompt injection, either direct or through content the agent read. Its root causes are excessive functionality, excessive permissions and excessive autonomy.

What the evidence looks like

Agent trouble is visible in tool calls, not in error logs. Everything can return 200 and still be wrong. A useful record has one event per tool call.

{
  "ts": "2026-11-08T09:14:52Z",
  "run_id": "run_7c1e",
  "agent": "support-assistant",
  "acting_for": "user_2093",
  "tool": "admin.refund_order",
  "args_summary": "order=o_8841 amount=240.00",
  "status": "ok",
  "step": 9
}

This is an example. For a support agent whose usual tools are kb.search and ticket.reply, one admin.refund_order call is the whole story. OpenTelemetry's GenAI conventions define an execute_tool operation and tool call attributes you can use for the same data. They are still at Development status, so pin the version you emit.

How to detect it

1. Instrument every agent with a run id, an agent name and the user or system it acts for. Emit one span or log event per tool call.
2. Write down each agent's allowed tools. Start from the last 30 days of observed use, then trim it by hand.
3. Compare every call to that list and to history.

-- Tools an agent has never used before, last hour
SELECT c.agent, c.tool, count(*) AS calls, min(c.ts) AS first_seen
FROM tool_calls c
WHERE c.ts > now() - interval '1 hour'
  AND NOT EXISTS (
    SELECT 1 FROM tool_calls h
    WHERE h.agent = c.agent AND h.tool = c.tool
      AND h.ts BETWEEN now() - interval '30 days' AND now() - interval '1 hour'
  )
GROUP BY c.agent, c.tool
ORDER BY calls DESC;

Add three more checks. Runs with an unusual number of steps:

SELECT run_id, agent, count(*) AS steps, count(DISTINCT tool) AS tools
FROM tool_calls
WHERE ts > now() - interval '1 hour'
GROUP BY run_id, agent
HAVING count(*) > 50
ORDER BY steps DESC;

Repeated identical calls inside one run, which usually means a loop. Calls to a sensitive tool list (refunds, deletes, permission changes, outbound email) with a human approval check. And a mismatch between the user the agent acts for and the account whose data it touched.

Thresholds and pitfalls

A tool never seen before is a prompt, not a verdict. New features add tools, so suppress alerts for tool names that appear in the same deploy that shipped them. Step counts vary by task: set the limit per agent from its own distribution, such as a multiple of its 99th percentile, and not one global number.

Treat sensitive tools differently from normal ones. A single call to a destructive tool deserves a look every time, even at a normal rate. A normal tool at ten times its usual rate deserves one too.

Beware of logging secrets. Tool arguments often hold personal data and credentials. Log a summary or hashes, not raw payloads. Finally, an agent's behavior depends on the model version and the prompt, so record both on every run. A change in tool mix right after a prompt edit is an expected change, not an intruder.

What to do when it fires

Pause the agent or revoke its credential first, then investigate. Replay the run from its run id and read the input that came before the first odd call. If external content was in the context, suspect prompt injection.

Then close the cause. OWASP's mitigations are concrete: offer the minimum set of tools, keep each tool narrow and avoid open-ended ones such as a raw shell, give tools minimum permissions and run them in the user's context, require human approval for high-impact actions and enforce authorization in the downstream system instead of trusting the model.

Related guides: LLM behavior drift covers changes in model output, and authentication anomalies covers misuse of the credentials agents hold. If you export agent traces, the OpenTelemetry page shows how to send them, and the Mastra and Claude Code pages cover two agent frameworks that can emit them.