ASD ISM 2159 Centrally log agentic AI tool invocations, external requests and outputs
What it says
All tool invocations, external requests and outputs generated by agentic AI applications are centrally logged with sufficient detail to support cyber security incident investigations.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishAgentic AI applications must send a detailed record of every tool call, outbound request and generated output to central logging so incident responders can reconstruct what the agent did.
An agentic AI application does not just answer questions. It takes actions: it calls tools (running code, reading files, sending emails, querying databases), it reaches out to external services and websites, and it produces outputs that people or other systems act on. This control requires that all three of those things, every tool invocation, every external request and every output, are logged to a central location, and that the logs carry enough detail to be useful in a cyber security incident investigation. Why it matters: an agent can be manipulated through prompt injection, a compromised tool, a poisoned data source or a stolen credential, and it can then take harmful actions quickly and at scale. When that happens, investigators need to answer concrete questions. Which tools did the agent call, with what parameters, and when? What did it send to which external endpoints? What did it generate and where did that output go? If those records only exist on the agent host itself, or exist only as a vague summary, the trail is incomplete or can be destroyed by the same attacker. Central, detailed logging turns an agent's behaviour into evidence that can be searched, correlated with other security telemetry and preserved for the investigation.
Free. Save your status, tasks and notes.
Why it matters
Without central, detailed logs of agent tool calls, external requests and outputs, an organisation cannot reliably determine what a compromised or misbehaving agentic AI application actually did. Scoping a cyber security incident becomes guesswork: data may have been exfiltrated through an external request, destructive tool actions may have been taken, or harmful outputs may have been delivered to users, and none of it can be proven or ruled out. Investigation and containment are delayed, evidence may be lost or tampered with on the agent host, and the organisation may be unable to meet its reporting and accountability obligations after an incident.
How to implement
The AI platform owner should inventory every agentic AI application in use and, for each one, enumerate the tools it can invoke, the external endpoints it can reach and the channels its outputs are delivered through, so that the full logging scope is known before configuration begins.
Engineering teams should configure each agent framework or orchestration layer to emit a structured log event for every tool invocation, capturing the timestamp, session and user identity, tool name, input parameters and returned result, rather than relying on the model's own summary of what it did.
Engineering and network teams should capture every external request made by an agent, including the destination, method, request content and response status, by logging at the agent's HTTP client or connector layer and, where possible, corroborating it with egress proxy or gateway logs.
The AI platform owner should log the outputs the agent generates, including the content and where it was delivered (a user, a file, another system), and link each output to the session and the tool calls that produced it so investigators can trace cause and effect.
Security operations should forward all of these agent events to the central logging or SIEM platform over an authenticated channel, apply retention that meets investigation needs, and periodically replay a sample session from the central logs alone to confirm the detail is sufficient for an incident investigation.
Keep it running
Day to day, this control lives in the integration between each agentic AI application and the organisation's central logging platform. Every agent deployment should be registered as a log source, with the three event families (tool invocations, external requests, generated outputs) mapped to a consistent schema that captures at least the timestamp, agent or session identifier, the acting user or service principal, the tool or endpoint called, the parameters or request content, and the result or output produced.
Operational teams should check regularly that each agent is still shipping all three event types, since a change to the agent framework, a new tool being added, or a new external connector can silently introduce a gap. Log volume from agents can be high, so retention, storage and any truncation rules need to be set with investigation needs in mind: a record that has been trimmed of the tool parameters or the request body may no longer be sufficient to support an investigation. Incident responders should periodically exercise the logs by reconstructing a sample agent session end to end, which is the most direct way to confirm the detail is sufficient.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the list of agentic AI applications in use and the logging configuration for each one.
Look at
Check that every agent on the list is a registered source in the central logging platform and that the configuration covers tool invocations, external requests and outputs, not just one or two of them.
Good evidence
Every agent in production is sending all three event types to the central platform, and there are no agents that log only locally or not at all.
- Check 2 of 5What an auditor asks for
Ask for
Ask for a sample of raw tool invocation log entries from the central logging platform for a recent period.
Look at
Look at whether each entry records when the call happened, which session and user it belonged to, which tool was called, what parameters were passed and what came back.
Good evidence
The entries are structured and detailed enough that an investigator could tell exactly what action the agent took and on whose behalf, without needing access to the agent host.
- Check 3 of 5What an auditor asks for
Ask for
Ask for central log entries showing the external requests made by an agent, alongside any corresponding proxy or gateway records.
Look at
Check that destinations, request content and outcomes are captured, and compare the agent-side records with the network-side records to see whether they agree.
Good evidence
All outbound requests appear in the central logs with enough detail to identify what was sent where, and network records corroborate them with no unexplained gaps.
- Check 4 of 5What an auditor asks for
Ask for
Ask for central log entries showing outputs generated by an agent and where they were delivered.
Look at
Look at whether the output content and its destination are recorded and whether each output can be linked back to the session and tool calls that produced it.
Good evidence
An investigator can follow a chain from a generated output back through the tool calls and requests that led to it, all from the central platform.
- Check 5 of 5What an auditor asks for
Ask for
Ask for evidence of a recent exercise or real investigation in which an agent session was reconstructed from the central logs.
Look at
Check whether the reconstruction succeeded using only the central logs and whether any gaps or insufficient detail were identified and remediated.
Good evidence
The organisation has demonstrated that the logs are actually sufficient to investigate agent activity, and any shortfalls found have been fixed rather than left open.
Mappings
Closest match in ISO/IEC 27001: A.8.15, Logging of activities and events, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.15.
ISM-2159 requires that all agentic AI tool invocations, external requests, and outputs are centrally logged with enough detail to support cyber security incident investigations. ISO/IEC 27001:2022 Annex A 8.15 requires that logs of activities, exceptions, faults, and other relevant events are produced, stored, protected, and analysed, which is a broad organisational logging requirement that would include AI application/agent events as a subset. ISM-2159 is more prescriptive about the specific AI-agent event types (tool calls, outbound requests, generated outputs) and centralisation, whereas Annex A 8.15 covers logging across all systems and event classes.
This control supports A.5.28.
ISM-2159 requires the organisation to generate and centrally collect detailed records of agentic AI tool calls, external requests, and outputs for incident investigations. ISO/IEC 27001:2022 Annex A 5.28 requires procedures for identification, collection, acquisition, and preservation of evidence related to information security events, which directly governs how ISM-2159-produced AI audit logs should be handled as evidence (e.g., preservation and integrity). Annex A 5.28 is process/chain-of-custody focused, while ISM-2159 is a technical evidence-generation requirement specific to agentic AI activity.
ISO/IEC 42001: 1 mapping
This control partially meets A.6.2.8.
ISM-2159 requires central logging of every agentic AI tool invocation, external request, and output, with investigation-grade detail. ISO/IEC 42001:2023 Annex A 6.2.8 requires the organisation to enable AI system event log recording across relevant life cycle phases (at minimum when the AI system is in use), which is a broader governance requirement about when logging is enabled. ISM-2159 is a specific operational implementation expectation for agentic AI runtime behaviour and central log collection, while Annex A 6.2.8 is less specific about the exact event categories and whether logs must be centralised.
ASD Essential Eight: 1 mapping
- E8-AH-ML2.11Centrally log PowerShell module, script block, and transcription eventsPartially overlaps
This control partially overlaps E8-AH-ML2.11.
ISM-2159 requires central logging of agentic AI tool calls, external requests, and outputs with sufficient detail for incident investigations. ASD Essential Eight E8-AH-ML2.11 requires central logging of PowerShell module, script block, and transcription events, which overlaps when an agentic AI invokes PowerShell as a tool (capturing the executed content and transcripts as part of the audit trail). ISM-2159 extends beyond PowerShell to any tool mechanism and explicitly requires logging of outbound requests and generated outputs, which E8-AH-ML2.11 does not address.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.