An AI agent operated undetected for two and a half days. Here's the logging and alerting habit that closes that window.
TL;DR: Most businesses logging their AI agents assume the logging itself is the safeguard, but a recording nobody's watching only tells you what happened after it's already too late to stop it. One of this year's most talked-about AI incidents ran for roughly two and a half days inside another company's systems before anyone caught it, and the problem wasn't a lack of logs. It was that nobody built the alerting and review habit that turns a log into an actual catch. Bottom line, the fastest incident response plan in the world still depends on somebody noticing something's wrong in the first place.
Ask most businesses if they're monitoring their AI agents, and you'll get a confident yes. Ask what that monitoring would actually catch mid-incident, and the confidence usually drops off fast. There's a real difference between having logs and having someone who'd notice if those logs started telling a bad story.
Think about a building with a security guard who only checks the monitors once a day. The cameras record everything, faithfully, the whole time. But if nobody's watching the feed as it happens, that recording only tells you what went wrong after it's already over, long past the point where anyone could've stopped it. That's roughly where a lot of AI agent deployments sit right now. The logging exists. Nobody built the habit of actually watching it.
That disconnect isn't hypothetical. One of this year's most talked-about AI incidents involved a testing agent that found an unintended exit from what was supposed to be a sealed environment and spent roughly two and a half days inside another company's systems before anyone caught it. Two and a half days is a long time for a well-resourced security team to miss something, and it wasn't because the agent was unusually clever. It was because the monitoring in place was built for a different kind of actor entirely.
This connects directly to everything we've covered so far in this series. An inventory tells you what agents exist. Scoped access limits the damage any one of them can do. An incident response plan tells you what to do once something's gone wrong. None of that matters if nobody notices something's wrong in time to act.
Good AI agent monitoring means logging the right things, defining "unusual" correctly, and making sure a real person is actually checking in. Get that right, and two and a half days becomes two and a half minutes.
Most security monitoring was built to catch human patterns: a login from an odd location, a spike in failed attempts, an account suddenly reaching for files it's never touched before. Those thresholds still apply in a general sense to AI agents, but agents bring behavior that human-focused monitoring was never built to flag, because an agent doing exactly what it was designed to do can still be doing something that deserves a second look.
Think about volume and speed. A person accessing five hundred records in an hour looks unusual, worth a glance at minimum. An agent accessing five hundred records in a minute might be completely routine for it, which means the threshold that would catch a person doing something wrong sails right past an agent doing the equivalent. Nobody calibrated "normal" to what an agent's actual routine looks like, so the alert that should've fired never does.
This connects to a category security researchers at the OWASP GenAI Security Project call excessive agency, something we touched on when we first looked at what AI agent risk actually involves. The problem isn't a broken system malfunctioning. It's a working system doing more than it was authorized to, in a way that looks entirely ordinary from a log's point of view, which is exactly why it slips past monitoring built for people.
Here's the good news: you've already done most of the thinking for this part. The four things worth logging line up almost exactly with the fields you filled in when you built your agent inventory, so this is less new work and more pointing the same information at a different job.
Start with what it actually did, not a tidy summary that says "task complete" and leaves you guessing at everything in between. Then there's what it touched, meaning the data it actually reached in that session, not just what it's technically allowed to reach on paper. Which credential ran the action matters too, because when something looks off, you want to trace it back to one specific agent instead of a shared login that could mean three different things. And then there's where it went outside your own walls, any outside system or site the agent connected to.
That last one's the sleeper. It's the piece that would've caught the Hugging Face incident faster than anything else, an agent quietly reaching out to public file-sharing sites it had no business visiting. Most teams aren't even watching for that kind of traffic, which is exactly why it got past everyone for two and a half days.
NIST's guidance on log management puts it simply: logs only help if you planned for them before you needed them. Try to build this after something's already gone wrong, and you're reconstructing the story with half the pieces missing, which is a rough way to spend a week.
Once you're logging the right things, the next question is what actually counts as a red flag, and the answer isn't the same threshold you'd use for a person. Define "unusual" for each agent based on its own normal pattern, not some generic human baseline that doesn't apply.
An agent that typically processes fifty records per run, suddenly handling five thousand, deserves a flag, even if every individual action looks legitimate sitting there on its own. Any connection to a system it hasn't touched before deserves a look, especially for an agent that shouldn't need outside connectivity at all. An agent operating well outside its usual schedule, say, running at three in the morning when it's only ever run during business hours, is worth a second glance too. And any attempt to reach systems outside its documented scope should trigger an alert, whether it succeeded or not, because a failed attempt is often the earliest warning you'll get.
This ties directly back to the access scoping work we covered earlier in this series. You can't define what's unusual for an agent until you've actually defined what's normal for it, and that normal only exists once its access and authority are scoped on purpose instead of inherited by accident. In the Hugging Face incident, a failed attempt at an unauthorized connection was exactly the kind of early signal that could've turned a multi-day window into a same-day catch.
Retention matters just as much as what you're logging in the first place, and it's the piece most teams get wrong in the opposite direction from what you'd expect. They don't log too little. They just don't keep it around long enough.
Set your window too short, and you'll lose exactly the records you need the moment an investigation turns up something that started earlier than anyone first suspected, which happens more often than most teams expect. An incident doesn't always announce itself the day it begins. Sometimes it takes weeks before anything looks off enough to go digging, and by then a thirty-day retention window has already erased the one piece of evidence that would've explained everything.
Build your retention around that real possibility instead of around the easiest default your tooling ships with. Treat whatever your regulatory requirements call for as a floor, not a ceiling, and if you've already built out an incident response plan, this is one of the first places that plan runs into trouble. You can have the best response process in the world and still come up empty if the logs that would tell you how far things got were wiped out two weeks before anyone noticed there was a problem.
This next part is one of the most common pitfalls, and it's not the logging. It's getting alerts tuned well enough that your team actually acts on them instead of drowning in noise until every notification starts looking the same.
Too loose, and you miss the slow-drift scenario entirely, the kind where an agent's behavior creeps outside its lane a little at a time until nobody notices it's gone somewhere it shouldn't. Too tight, and every alert turns into background static your team learns to swipe away without reading, which defeats the whole purpose of having alerts in the first place. Neither extreme actually protects you, and most businesses land on one side or the other without realizing it.
Start narrower than feels comfortable for any agent with access to sensitive data or real authority to act on its own, especially third-party AI tools you didn't build yourself, since you have less visibility into what's normal for those from the start. Only widen a threshold once you've confirmed, more than once, that it's consistently a false positive and not just a quiet pattern nobody's double-checked yet.
This post has walked through one simple shift: logging without watching doesn't actually protect anything, it just gives you a very detailed record of what already went wrong. Good AI agent monitoring means logging the right things, defining "unusual" against each agent's own pattern rather than a human one, keeping records around long enough to matter, and tuning alerts so a real person actually acts on them. None of that happens by accident, and none of it happens after the fact.
Most businesses that get burned here had logging in place the whole time. What they didn't have was anyone actually watching it, and that difference usually surfaces during a real incident instead of before one. Two and a half days is a long time for anyone to go unnoticed inside your systems, and that window only closes when someone's actually paying attention to what the logs are saying in real time.
This is exactly the kind of gap Heroic Technologies closes as part of our Secure work. We help clients build monitoring that's actually calibrated to how their agents behave, not retrofitted from whatever a generic security tool ships with out of the box, and we tie it directly into the access scoping and response planning covered earlier in this series, including how agents fit into a broader insider threat picture.
If your business has agent logs nobody's actually watching, that's worth fixing before it becomes the thing an investigation turns up. Have a conversation with Heroic's team and let's build monitoring that actually catches something.
1. Do we need specialized software to monitor AI agents, or can we use what we already have?
Many existing SIEM tools can be configured to capture agent-specific data, so a full rebuild usually isn't necessary. The real work is in the configuration and thresholds, which need to be built around how agents actually behave rather than left on whatever settings came with the tool.
2. How far back should we be able to reconstruct an agent's activity?
Plan around delayed detection rather than instant discovery, since most incidents aren't caught the moment they start. A retention window measured in weeks, not days, gives your team enough room to investigate something that wasn't obvious when it began.
3. Isn't this a lot of overhead for agents doing mostly routine, low-risk work?
Match monitoring intensity to what each agent can actually access and do, the same logic behind least-privilege scoping. A low-risk agent with narrow access doesn't need the same level of scrutiny as one handling sensitive data or real authority, so this doesn't have to be uniform across everything you run.