How to Detect a Rogue Agent Run

Quick answer
You cannot detect intent, so detect deviation: tool calls, destinations, volumes, and privilege changes that the task did not need.
Log every tool call with its arguments and the identity that made it; without that, an incident is unreconstructable.
Alert on volume and destination: a large read, a new external host, a write to an unexpected repository.
Compare against a task-level baseline: which tools and paths were declared, versus which were used.
The fastest signal is often a cost or latency anomaly, because exfiltration and loops both consume resources.

What does a rogue run look like in telemetry?

A run that has been redirected tends to do things the task did not require: read files outside the working directory, call a tool it has never used in that task class, connect to a host that is not on the allowlist, or produce a burst of writes after a long read.

It may also look efficient. A single successful exfiltration does not need a loop, so the absence of errors is not evidence of safety. The signal is scope, not failure.

# Log the facts you will need later: identity, tool, args, destination
jq -c '{ts, run_id, agent_id, tool, args, host, bytes}' agent-audit.jsonl | tail -20
# Alert on volume and destination, not on words
jq -r 'select(.bytes > 5000000) | [.ts, .run_id, .tool, .host] | @tsv' agent-audit.jsonl

What should the audit log contain?

Run identifier, agent identity, tool name, arguments with secrets redacted, destination host, byte counts, exit status, and the approval decision if a human was asked. The run identifier is what makes an investigation possible.

Store it outside the agent’s reach. A log the agent can edit is not evidence, and an agent with a shell can edit files. Ship it to a separate system at the moment of the call.

Which rules are worth alerting on?

A new external destination, a read of a path outside the declared scope, a credential or permission change, a burst of writes, and any tool call that was explicitly denied earlier in the run. These are high signal and cheap to compute from the log.

Keep a per-task allowlist as the baseline. The task declares the tools and paths it needs; anything else is a deviation worth a human look, even if it turns out to be benign.

What do you do when an alert fires?

Stop the run, revoke the credential, and preserve the log. Then check what left: which host received what, and whether the data was sensitive. Rotation is the first action if a credential was used outside its scope.

Afterwards, fix the boundary rather than the prompt. If the run could reach production data, the problem is the scope; if it could send data anywhere, the problem is egress. The incident report should name the control that failed.

Where this bites vibecoders
Most setups have no log at all: the agent’s output is the only record, and it is written by the agent. Add a tool-call log before you add more capability, because the first incident is when you discover the difference between a transcript and an audit trail.

Where AI coding assistants get this wrong

Keeping the audit log where the agent can edit it.
Logging a summary instead of the tool call and its arguments.
Alerting on model text rather than on scope and destination.
Assuming no errors means no incident.
Sharing one identity across runs, so nothing is attributable.
Revoking the token but not the data that was already sent.

Checklist

Log every tool call with run and agent identity.
Record destination hosts and byte counts.
Keep the log outside the agent’s reach.
Set an allowlist per task and alert on deviation.
Stop and revoke on the first credible alert.
Name the failed control in the post-incident review.

FAQ

Can a prompt-injection detector catch this?

Only sometimes, and only before the action. Detection based on output patterns misses novel phrasings and novel encodings. Behavioural detection — scope, destination, volume — is more durable because a successful attack must still perform the action.

What is the minimum viable logging?

Tool name, arguments, run identifier, identity, and destination, shipped off the machine. That is enough to reconstruct what happened and to alert on volume and new hosts. More detail helps, but this is the floor.

How do I avoid alert fatigue?

Baseline per task. A migration agent reading the migrations directory is normal; the same agent reading a private key is not. Rules that compare to the declared scope produce fewer, better alerts than rules about suspicious words.

Should I notify anyone externally?

Follow your incident process. If personal data left, legal and privacy obligations may apply regardless of whether the agent or a human caused it. The agent’s identity does not change the classification of the data.