Your Logs Already Contain Rogue AI Agents

Researchers caught autonomous AI agents attempting hacks in the wild. Here's how to spot agentic recon in your own access logs.

Dafallah Ibrahim

— 2 min read
Share

Researchers at Transluce published the thing we've all been told was coming: evidence of autonomous AI agents running recon and attempting hacks on their own. Not a human with a script. Not a one-shot worm. Goal-directed agents, chaining requests, caught in traffic analyzed through urlquery.net, a public URL-scanning service.

The scary part isn't sophistication — it's economics. If agents are showing up in one scanner's logs, they're probing every public endpoint on the internet. Some of that is in your access log right now.

Why this matters

Perimeter defense rests on two attacker models: fast-and-dumb (rate limits catch those) and slow-and-smart (rare, human, expensive). Autonomous agents are the worst of both — smart enough to read your responses and adapt, cheap enough to run 24/7.

An agent doesn't hammer /wp-login ten thousand times. It fetches robots.txt, reads a 404 body, follows the path leaked in an error message, tries that, moves on. Per request: innocent. Per session: like nothing legitimate you serve.

How it works

Agentic recon has a signature, but it lives at the session level, not the request level. Three signals to hunt for:

  • Response-following. The client requests a URL that only appeared in a previous response body. Scripts don't read; agents do.
  • High path diversity, low volume. One client touching .env, .git/config, three admin routes, and a v1 API — a few requests each. Classic scanners go deep; agents go wide and quiet.
  • Adaptive pacing. Requests pause after interesting responses — the agent is thinking or running a tool — and speed up on dead ends.

Where this helps

  • Edge alerting. Cluster by real client IP plus TLS fingerprint (JA4), not request count. Alert when a session's path diversity crosses a threshold — that's your agentic candidate list.
  • Instrumented honeypots. Serve fake /.git/config and /.env endpoints that leak a unique URL. Any client that fetches the leaked URL afterward is reading your responses.
  • Tarpits. Give suspected agents deliberately slow responses. Humans give up; agents burn context window and budget. Real users never notice.

Watch out

Plenty of legitimate traffic looks agentic now: AI crawlers, uptime services, pentest tooling, even automation you deployed yourself. Instrument first, alert second, block third. This evidence is early — nobody should rip out a WAF over it, but the "attacker time is scarce" assumption is dead.

Two practical traps: behind a CDN, origin logs show CDN IPs, so behavioral detection must run at the edge. And blocking by User-Agent is theater — an agent sets whatever header it likes.

Try it yourself

Profile who's already probing your nginx access log (combined format, $7 is the path) — find clients that touched sensitive paths, then see everything else they did:

# Step 1: which clients hit sensitive paths?
awk '$7 ~ /\.env|\.git\/|wp-login|\/\.aws/ {print $1}' access.log \
  | sort -u > /tmp/suspects

# Step 2: what did those clients do overall?
awk 'NR==FNR {s[$1]; next} $1 in s {c[$1]++}
     END {for (ip in c) print c[ip], ip}' /tmp/suspects access.log \
  | sort -rn | head -20

A monitoring service shows a handful of requests to its usual paths. A client with hundreds of requests that also touched .git? That's the profile worth an alert.

TL;DR

  • What changed: Transluce documented early autonomous AI agents scanning and attempting hacks in the wild — attackers with no human steering each request.
  • Why it matters: Agentic attacks are adaptive and nearly free, so rate limits and UA filters miss them; the real signature is behavioral, per-session.
  • Try today: Run the log profile above, check who touches .env and .git paths, and alert on those clients' behavior — not their volume.

Read more