Newsletter Article

Can You Prove What Your AI Did?

Snare Insider Newsletter Series Article

Make sure you Subscribe

SUBSCRIBE
Back to Snare Insider Issue 15

If AI becomes part of the decision chain, it must also become part of the evidence chain.

The AI conversation in cybersecurity has moved on.

For the past two years, the question most security leaders were asked was whether their teams should use AI at all. That question has largely been answered. AI is already summarising alerts, enriching investigations, drafting detections and, increasingly, taking action on behalf of the people who deploy it. Gartner expects that by 2028, 15% of day-to-day work decisions will be made autonomously through agentic AI, and that a third of enterprise software applications will include agentic capabilities.[1]

That is a significant opportunity for security operations. Agents that can gather evidence, correlate activity and propose a containment step in minutes give stretched SOC teams real leverage.

But it changes the question security leaders now need to answer:

What authority should an AI system have — and how do you prove what it did with that authority?

The question everyone is talking about

This week, two of the year’s major practitioner events are running on opposite sides of the world: InfoSec World in Orlando (11–15 October) and CyberCon in Melbourne (14–16 October). Their programs approach AI from different directions, but they arrive at the same place.

At CyberCon, the Umpiring AI decisions session borrows cricket’s Decision Review System to propose a governance model that makes AI outputs “contestable, logged and defensible under audit”.[2] Alongside it, sessions on building enterprise AI governance and on governing autonomous agents argue that policy statements alone are not controls — autonomous systems need enforceable, runtime boundaries.

InfoSec World comes at it through identity. When AI Agents Go Live: Who Controls Their Access? asks what credentials and permissions agents are using as they access sensitive data and call APIs, and frames agents as identities that need continuous governance rather than applications to be secured once.[3] Invisible Administrators goes further, arguing that most enterprise privilege now sits with non-human identities — service accounts, OAuth apps, automation, integrations and AI agents — that are frequently unseen and long-lived.[4] And a workshop on Designing Auditable AI Systems maps where security and compliance controls belong across AI pipelines, aligned to the NIST AI RMF, ISO/IEC 42001 and CSA’s AI Controls.[5]

Put those threads together and the picture is clear. AI agents now carry many of the characteristics security teams have always associated with privileged users: an identity, credentials, access to sensitive information, connections into enterprise applications and the authority to execute actions.

We already know how to govern privileged users. We log what they do.

AI activity needs to become observable activity

Consider an AI-enabled security workflow that recommends — or initiates — a response to an identity alert. It queries authentication logs, pulls endpoint telemetry, checks the user’s group memberships and then disables an account and isolates a host.

Six months later, an auditor, a regulator or your own incident review asks you to explain that decision. Could you establish:

  • which identity initiated the interaction — and which human or process the agent was acting on behalf of?
  • what data the AI was authorised to access at that moment?
  • which logs or evidence informed the recommendation?
  • which applications, APIs or tools it invoked, and in what sequence?
  • whether its permissions changed during the process?
  • what action it recommended?
  • what action was actually executed — and by whom?
  • whether a human approved, modified or rejected it?
  • what happened immediately afterwards?

If those questions can’t be answered, the problem isn’t AI explainability. Explainability is about why a model produced an output. This is something more fundamental.

It is an evidence gap.

OWASP’s work on agentic AI threats names this precisely. Its threat taxonomy includes Repudiation & Untraceability — the condition in which “actions performed by AI agents cannot be reliably traced back or accounted for due to insufficient logging or transparency” — alongside Identity Spoofing & Impersonation and Privilege Compromise.[6] All three are, at root, questions about whether the evidence exists.

The cost of not having that evidence is already measurable. IBM’s Cost of a Data Breach Report 2025 found that 13% of organisations reported a breach involving an AI model or application; of those, 97% said they lacked proper AI access controls. Across all organisations studied, 63% either had no AI governance policy or were still developing one.[7]

Logging needs to follow the action

Traditional audit logging was designed around a familiar cast: human users, applications, operating systems and infrastructure. A Windows logon generates an event ID 4624. A privileged logon adds 4672. A new process is 4688. A user added to a security-enabled global group is 4728. Every one of those events can be attributed to an account, a host and a time.

Agentic systems introduce another actor into that cast — and one that frequently operates through the others. An AI agent may authenticate as a service principal, query a data store, call another service’s API, modify infrastructure or trigger a remediation playbook. Some of those actions will surface in existing logs; many will appear only as an API call made by a generic service account, with no indication that an AI decided to make it.

To be useful as evidence, AI-initiated activity needs the same characteristics security teams expect of any other security-relevant event:

Attribute What to capture for AI-initiated activity
Identity The agent’s own workload or service identity and the human or process it acted on behalf of (the delegation chain)
Timestamp Synchronised, timezone-normalised time for each step — request, tool call, decision, action
Source The AI system, model and version, and the interface or orchestrator that invoked it
Target The system, dataset, API or resource acted upon
Action The query, tool invocation, configuration change or command performed
Outcome Success, failure, partial completion — and the resulting state change
Context The evidence the AI relied on, the permissions in force, the approval state, and a correlation ID that links every step in the chain

That correlation ID matters more than it might appear. A single agentic task can generate events across an identity provider, a cloud control plane, an EDR console and a ticketing system. Without a common reference, an investigator is left trying to infer which events belong to which decision.

Independence is what makes it evidence

There is a second requirement that is easy to overlook.

An AI application’s own conversation history or activity panel is useful for the people using it. It is not, on its own, an audit trail. If the only record of what an agent did is held by the agent’s own platform, the same system that took the action is also the sole witness to it.

That’s the same principle security teams already apply to privileged administrators: the administrator’s actions are recorded somewhere the administrator can’t alter. Event ID 1102 — the audit log was cleared — exists precisely because the integrity of the record matters as much as its contents.

For AI, that means the logs describing agent activity should be:

  • collected independently of the AI application, from the systems the agent touched as well as from the agent itself;
  • protected against modification, including by the identities the agent uses;
  • retained long enough to answer the question when it’s actually asked — which may be months after the event; and
  • searchable alongside the rest of your security evidence, so an AI action can be placed in the same timeline as the human and system activity around it.

Regulation is moving in the same direction. Under the EU AI Act, high-risk AI systems must technically allow for the automatic recording of events over their lifetime (Article 12), and providers must keep those automatically generated logs for at least six months unless other law specifies otherwise (Article 19).[8] ISO/IEC 42001, the AI management system standard, includes a specific Annex A control (A.6.2.8) requiring organisations to determine at which life-cycle phases event logging should be enabled for an AI system — at a minimum, while it is in use.[9]

AI inside the SOC

This becomes particularly important when AI is used inside the SOC itself — the place where the integrity of evidence matters most.

InfoSec World’s From Alert to Evidence session explores natural-language investigation: analysts asking plain-language questions across live endpoints to collect artifacts, correlate evidence and reconstruct attacker activity. The session pairs that speed with a clear set of controls — authorised scope, transparent actions, evidence-grounded findings, human validation and a defensible record.[10]

That’s the right model, and it’s worth stating plainly:

AI can accelerate an investigation. It shouldn’t replace the underlying evidence.

An AI assistant that summarises a lateral-movement chain in seconds is enormously valuable. But the summary is only as defensible as the events it was built from — and those events need to exist, intact and attributable, independently of the assistant that read them. The best AI-assisted investigations will be the ones where every finding can be traced back to a specific log record that a human analyst can open and verify.

The security question for 2026

None of this is an argument for slowing AI adoption. It’s the opposite. Organisations that can demonstrate exactly what their AI systems did will be the ones able to grant those systems more authority, more quickly, with the confidence of their boards, auditors and regulators.

So as organisations move further into autonomous and agentic systems, security teams should add one requirement to every AI governance framework:

Can we reconstruct the actions of the AI system as reliably as we can reconstruct the actions of a privileged administrator?

If the answer is no, logging and auditability need to become part of the AI architecture from the start — designed alongside identity, permissions and approval workflows — not something added after deployment.

Five practical steps

  1. Inventory your agents. You can’t log what you don’t know is running. Include embedded AI features in SaaS platforms, not only the agents you built.
  2. Give every agent its own identity. Avoid shared service accounts. A distinct workload identity per agent makes every downstream event attributable.
  3. Log the delegation chain. Record which human or process each agent was acting for, and when a human approved, modified or rejected its recommendation.
  4. Collect from the systems the agent touched, not only from the agent: identity provider, cloud control plane, SaaS audit logs, endpoints and the AI platform itself.
  5. Retain and protect that evidence independently, for long enough to answer the question when it’s asked — and test that you can.

Where Snare fits

Snare’s role is the evidence layer underneath these decisions.

Snare Agents collect security events from Windows, Linux and other endpoints and servers, while identity, cloud, SaaS and network sources feed Snare Central directly via syslog, API and cloud audit feeds.

Snare Central retains a complete copy of that evidence for search, reporting and forensic investigation, independently of any analytics platform.

Snare Reflector routes selected events to the SIEM, data lake or other destinations based on the organisation’s own rules. Filtering shapes what each destination receives, not what is kept.

AskSnare, Snare’s cybersecurity AI assistant, is built on the same principle this article describes: it works from that evidence layer rather than replacing it.

Key takeaway

If AI becomes part of the decision chain, it must also become part of the evidence chain.

The organisations that get the most from AI will be the ones that can prove what it did.

This week’s resource: Can You Prove What Your AI Did? — AI Security Investigation & Auditability Checklist. Eight areas to test whether AI-initiated actions in your environment can be reconstructed during an investigation or audit

Download AI Security Investigation & Auditability Checklist
Back to the Snare Insider Issue #15 ROI Calculator

References

  1. Gartner, “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027,” press release, 25 June 2025. Reported in SD Times: https://sdtimes.com/agentic-ai/gartner-more-than-40-of-agentic-ai-projects-will-be-canceled-in-next-few-years/
  2. CyberCon 2026 Program, “Umpiring AI decisions: The Decision Review System (DRS) framework for contestable and board-ready security governance,” Wednesday 14 October 2026: https://melbourne2026.cyberconference.com.au/program
  3. InfoSec World 2026, “When AI Agents Go Live: Who Controls Their Access?”: https://www.infosecworldusa.com/isw26/session/?iswid=4449866
  4. InfoSec World 2026, “Invisible Administrators: Non-Human Identities as the New Enterprise Attack Surface”: https://www.infosecworldusa.com/isw26/session/?iswid=4121361
  5. InfoSec World 2026, “From Hallucinations to Controls: Designing Auditable AI Systems in the Real World”: https://www.infosecworldusa.com/isw26/session/?iswid=4119042
  6. OWASP GenAI Security Project, Agentic AI — Threats and Mitigations (threats T3, T8, T9). Summary: https://humansecurity.com/learn/blog/agentic-ai-security-owasp-threats
  7. IBM Security, Cost of a Data Breach Report 2025. Reported in Help Net Security, 4 August 2025: https://www.helpnetsecurity.com/2025/08/04/ibm-cost-data-breach-report-2025/
  8. Regulation (EU) 2024/1689 (Artificial Intelligence Act), Articles 12 and 19: https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-19
  9. ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system, Annex A, control A.6.2.8 “AI system recording of event logs.”
  10. InfoSec World 2026, “From Alert to Evidence: Investigating Enterprise Threats in Natural Language,” Tech Theater, 14 October 2026: https://www.infosecworldusa.com/isw26/session/?iswid=4443726
Snare Insider Issue #15 – Oct 2026Detection Is Not Investigation
Snare Solutions
Powered by  GDPR Cookie Compliance (opens in a new tab)
Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.