- Log inputs, outputs, tool calls and the identity behind each agent.
- Logs limit damage and help investigations, but they do not prevent attacks.
- Alert on unusual tool use, data leaving through tools, and changes to tools or configuration.
- Send agent logs to the SIEM and link each task with one correlation ID.
What Should You Log For An AI Agent?
Log what goes into the agent, what comes out, and every tool it calls, along with the identity it used. NCSC says to monitor for prompt injection by logging inputs, outputs and tool calls. With those three records you can rebuild what an AI agent saw, what it decided and what it did.
This matters more for agents than for ordinary software. OWASP's Top 10 for Agentic Applications 2026 says strong observability becomes non-negotiable, because agents act on their own. NCSC lists the difficulty of detecting problems when actions happen quickly as a named risk, and says: "If you cannot understand, monitor or contain an agent's actions, it is not ready for deployment."
OWASP is clear about the limits of logging. In its Excessive Agency entry (LLM06:2025, 2025 edition) it says rate-limiting, logging and monitoring limit damage but do not prevent it. So logging supports the controls in our least agency checklist; it does not replace them.
Which Records Do You Need?
The sources point to five kinds of record. Together they answer the questions an investigator will ask after an incident.
| What to capture | Source |
|---|---|
| Inputs and outputs | NCSC recommends logging inputs and outputs when monitoring for prompt injection. |
| Tool calls | NCSC recommends logging tool calls. OWASP's agentic threat guide lists Repudiation and Untraceability (T8) as a threat. |
| Retrievals | OWASP (LLM08:2025) recommends detailed, immutable logs of retrieval activities in RAG systems. |
| Scope elevation | The MCP security guidance says to log elevation events, with the scope requested and the subset granted, using correlation IDs. |
| Token use | The MCP guidance warns that passing tokens through hides who did what and makes audit and investigation harder. |
Two more records are our practical suggestion rather than a requirement from those sources. Log each human approval, with who approved which action and when. And give every agent its own identity, so that its actions are never confused with a person's. See non-human identity for why this matters.
Keep sensitive data out of the logs where you can. Prompts and tool results can contain sensitive data, so logs that copy them can too. Mask or restrict what you can. Decide retention with your legal and privacy teams, because the sources do not set a period.
What Should You Watch For?
OWASP's agentic list suggests a behavioral baseline and checks at run time, with the agent paused when its goal shifts unexpectedly. In practice that means knowing what normal looks like for each agent: which tools it calls, how often, with what data, and at what times. Then alert on the gaps.
MITRE ATLAS, in its 2026.09 release, gives names to agent behavior worth watching. Use them as labels for detections, not as a complete list.
| Signal to look for | ATLAS technique |
|---|---|
| A tool called that the task did not need | AML.T0053 AI Agent Tool Invocation |
| Data leaving through a tool that can write, such as sending email | AML.T0086 Exfiltration via AI Agent Tool Invocation |
| Deletion or damage through a tool | AML.T0101 Data Destruction via AI Agent Tool Invocation |
| Changed or poisoned memory and context | AML.T0080 AI Agent Context Poisoning |
| A new or altered tool, such as an MCP server | AML.T0110 AI Agent Tool Poisoning |
ATLAS also covers LLM prompt injection (AML.T0051) in direct and indirect forms. You rarely see the injected text itself in an alert, so detections of the effects above matter more than detections of phrases. For the memory row, see memory and context poisoning in AI agents. NCSC adds that blocking lists of phrases is counterproductive as a defense.
Where Do Agent Logs Go?
Send them to the place your analysts already watch, normally your SIEM, so agent activity sits next to identity, endpoint and network events. Treat the log pipeline as a security control: restrict who can change it, and prefer storage that cannot be edited after the fact. OWASP asks for immutable logs for retrieval activity, and the same reasoning applies to the rest.
Use one correlation ID to link an agent's request, its tool calls and any approval. The MCP guidance uses correlation IDs for elevation events for exactly this reason. Your analysts can then follow one task from start to finish. For how analysts can use agents themselves, see agents in the SOC and threat intelligence, done safely.
Some tools write this trail for you. Brandefense says that Odin shows each step with its sources, and that its MCP server lists the tool calls behind an answer (see Odin and the MCP server). Ask any supplier what is recorded, for how long and who can read it. Those details are not stated on those pages.
What To Do Next.
- Pick one agent and list what it logs todayInputs, outputs, tool calls, approvals, identity.
- Close the gapsYou should answer: who asked, what did the agent read, which tools did it call, who approved, what changed.
- Give the agent its own identity and a correlation ID that spans a task
- Send the logs to your SIEM and write two or three alertsUse the signal table above.
- Reconstruct yesterday's work from the logs aloneFix what the tester could not see.
- Add the logging rules to your AI agent governance policy
The policy clauses are in the AI agent governance policy template. To test whether your alerts fire, see red teaming AI agents.
Sources
- 1 NCSC: Prompt injection is not SQL injection
- 2 NCSC: Thinking carefully before adopting agentic AI
- 3 OWASP LLM06:2025 Excessive Agency
- 4 OWASP LLM08:2025 Vector and Embedding Weaknesses
- 5 OWASP Top 10 for Agentic Applications 2026 (PDF)
- 6 OWASP Agentic AI Threats and Mitigations (PDF)
- 7 Model Context Protocol: Security Best Practices
- 8 MITRE ATLAS data release v2026.09