What your logs can’t tell you when an AI agent acts alone

What your logs can’t tell you when an AI agent acts alone For a long time, logs lived in a strange purgatory: technically required, rarely read, and mostly forgotten until something broke. The typical pattern looked like this: engineering teams would wire up logging because it was considered good practice, or because an auditor had it on a checklist. The logs got generated. They went somewhere — an S3 bucket, a Security Information and Event Management (SIEM) system, a flat file on a server — and then nobody looked at them. Not because teams were negligent, but because the logs weren’t built to be looked at. They were a dump. A timestamp and an event ID and a string of metadata that required real forensic patience to make sense of. The only time anyone went digging was after an incident. And that’s exactly when you’d discover the gap: “We’re not logging what we should have been logging.” By then, it’s already too late. The attacker has moved, the blast radius is unclear, and your investigation is running on incomplete evidence. “The question now isn’t whether you’re generating logs; it’s whether your logs can actually tell you something when it counts.” That world is gone. The question now isn’t whether you’re generating logs; it’s whether your logs can actually tell you something when it counts. The pressure didn’t come from one direction The shift didn’t come from a single regulation or a single breach. It came from pressure building on multiple fronts simultaneously. Regulatory frameworks started demanding demonstrable evidence, not just assertions. The SEC’s disclosure rules changed how public companies talk about security incidents. The NIS2 Directive (EU 2022/2555) raised the bar across critical infrastructure in Europe. Auditors who once accepted a screenshot of a logging policy now want to see the logs themselves, queryable and timestamped and tied to specific events. At the same time, developers and product teams started asking harder questions about the tools they were building on. Security awareness inside engineering organizations has matured. Teams evaluating new vendors now include security-minded engineers who want to know not just whether a product is SOC 2-certified, but also what the security logging actually looks like under the hood. Enterprise procurement followed the same pattern. Security review questionnaires got longer. Legal and compliance teams started pulling audit log samples during vendor evaluations. A product that couldn’t produce a clean, exportable activity log was starting to lose deals it would have won two years earlier. And then there’s the AI-powered attacker. Adversaries are moving faster than ever, and catching them in real time is increasingly difficult. What logs give you is the next best thing: a record of how they moved, what they touched, and what the attack pattern looked like. That record becomes the foundation for designing better defenses against the next one. AI agents are already provisioning resources, making purchases, modifying account settings, and deleting data inside production environments. Gartner projects that 33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024. By that same year, 15% of day-to-day work decisions will be made autonomously through AI agents. Every one of those autonomous actions is a candidate audit log entry that did not exist a year ago. The logging question is no longer just about what humans did. It now includes what agents did, who authorized them, and whether the action was within scope. The data backs up what security teams have been feeling. Verizon’s 2026 Data Breach Investigations Report analyzed over 22,000 confirmed breaches and found that exploitation of vulnerabilities now accounts for 31% of all initial access, overtaking credential abuse for the first time in the report’s 19-year history. Third-party involvement in breaches jumped 60% year over year, reaching 48% of all breaches. When initial access moves that fast and spans that many external relationships, the logging infrastructure is what determines whether you can reconstruct what happened after the fact. Roughly one in three breaches starts with a vulnerability exploited before most teams can patch it, and the ones that are identified can take an average of eight months to remediate. Logging is the difference between a postmortem and a guess. The difference between a log and a record Not all logging is equal, and that distinction matters more than most teams realize until they’re sitting in front of an auditor or an active incident. Surface-level logging captures that something happened. A real audit trail captures the full context around it: who took the action, what exactly changed, when it happened, where the request originated from, and what the state of the system looked like before and after. That difference between an event notification and a complete activity record is the difference between a log that confirms something occurred and a log that can actually reconstruct what happened. That bar gets higher when the actor is not a human. In a human-only environment, investigators can sometimes reconstruct intent from surrounding behavior. With an AI agent acting autonomously, none of that ambient context exists. The audit trail is the only source of truth. A complete activity record in an agentic world means capturing not just the action, but the agent identity, the authorization chain that initiated it, and the scope boundaries that were supposed to constrain it. “In a human-only environment, investigators can sometimes reconstruct intent from surrounding behavior. With an AI agent acting autonomously, none of that ambient context exists.” SOC 2 makes this concrete. Across several of its Common Criteria, SOC 2 Type II requires evidence that access to systems is logged, that changes to data and configurations are tracked, and that those records are tamper-evident and retained over time. A log that simply records “user logged in” doesn’t satisfy that. A log that captures the user, timestamp, IP address, session ID, and whether the authentication method was standard or elevated is getting there. The practical test is simple: If an incident happened six months ago, could your logs reconstruct the sequence of events clearly enough to brief a board, respond to a regulator, or hand it off to a forensic investigator? If the answer is uncertain, the logs aren’t operational yet. Actionable security logging has a few non-negotiables. Logs need to be immutable so they can be trusted as evidence. They need to be structured so they can be queried, not just read. They need to capture the right events, which means user actions, system changes, access grants and revocations, and configuration modifications, not just authentication events. Retention is another critical consideration. For some tools, 30 days of hot storage may be reasonable, but depending on the use case, 6 months of context might be what an investigation actually requires. Not all platforms handle this the same way. Some offer tiered retention with cold storage archives. Others require a support ticket just to access logs older than the default window. The easier it is to retrieve historical logs, the more credible your tool becomes during incidents and investigations, and the better the experience for the security teams relying on it. Your logging infrastructure is now a revenue asset A well-instrumented audit trail used to be an internal asset. It lived in a SIEM, it served the security team, and it surfaced during audits. Now it’s showing up in sales cycles. Enterprise buyers are asking for it during procurement. Legal teams are reviewing it before contracts get signed. And trust centers that surface clean, structured security content are being indexed by AI-powered procurement tools that summarize vendor risk before a human even gets involved. That puts security teams in an interesting position. The work they’ve been doing quietly for years, building reliable logging, maintaining tamper-evident records, structuring events in a way that’s actually queryable, is now directly connected to revenue. A buyer who can see a clean audit trail moves faster through the procurement process. A deal that might have stalled at the security review stage closes because the evidence was already there, accessible and credible. The Storm-0558 incident in 2023 made this concrete at the highest stakes possible. A China-linked group used a stolen Microsoft signing key to forge tokens and access mailboxes belonging to U.S. State Department and Department of Commerce officials. Roughly 60,000 unclassified emails were exfiltrated. The State Department detected the intrusion because it had paid for a higher tier of Microsoft Purview Audit logging that included mailbox access events. Other affected agencies on lower tiers did not have that visibility. After pressure from CISA and the U.S. Cyber Safety Review Board, Microsoft made the relevant audit logs available to all customers, regardless of license tier, within months. The lesson generalized quickly across the industry. Logging is not a premium feature. This is the competitive differentiator that doesn’t get talked about enough. Sales teams can’t manufacture trust in a security review. They can only surface what’s already been built. Security teams that instrument audit trails well are handing sales something real to work with. “Sales teams can’t manufacture trust in a security review. They can only surface what’s already been built.” The opportunity isn’t just about closing deals faster either. It’s about showing up differently in a market where most vendors still treat logging as an internal function. Enterprise buyers running AI-assisted workflows already need to answer their own boards and regulators when something goes sideways. If a product in their stack can’t produce a clean record of what an agent did and who authorize