# Logging for AI agents: what to record before an incident [Original page](https://danilolapegna.com/guides/audit-ready-agents-logging-italian-smb.html) Language: en. Content updated: 2026-10-16. What to record so you can reconstruct an AI agent's actions, respond to incidents and keep only the information you need. Take the case your logging must be able to explain: a customer-support agent sends one customer another customer's confidential price list. The first question is not “how intelligent was the model?” but “which identity called which tool, with which scope, on which version and with what result?”. Start with one operation and ask the logging owner to reconstruct its request, authorisation, tool call and confirmed result. Logs record events; a trace connects the events in one execution. A useful trace reconstructs the sequence without keeping every conversation in plaintext. An inadequate trace leaves two bad options: guess the cause, or discover that you logged more personal data than necessary. ## What to record, and what to leave out The tradeoff is between minimisation and reconstructability. GDPR requires data and retention to be necessary for their purpose; DORA requires financial entities to manage and report incidents, which a supplier may need to support by contract. Neither rule says “store everything”. The [AI Act + DORA timeline](https://danilolapegna.com/guides/ai-act-dora-eu-regulatory-timeline-italian-smb.html) separates customer duties from supplier evidence. The practical rule is to start with the “what” of the action, not the entire payload. Record that the agent called Salesforce, with which scope and outcome. Retain the body only for a defined purpose and with suitable redaction and access controls; it may contain personal or commercial data the trace should not duplicate. OpenTelemetry is an open standard for recording system activity. A trace groups a sequence; a span describes one operation. Span events do not automatically have separate retention. For content requiring independent access and deletion, use separate storage linked through an identifier. Test deletion in the actual system. ## A useful baseline for the log schema These nine fields are a starting point. Add or remove fields only according to the questions the runbook must answer. **Normalised timestamp**. Use ISO 8601, retain the offset or UTC and keep enough precision to order events. The goal is unambiguous correlation across systems. **Agent and versions**. Record the agent identifier, model, instructions, tools and configuration. A hash is a content fingerprint; the prompt hash alone does not identify the whole system. **Trace ID + span ID + parent span ID**. The identifiers link the overall run, the current operation and the operation that started it. This lets you follow the decision chain from user input to final action, including any sub-agent invocations. **Tool name + scope**. Name of the called tool + actual scope of permissions used. Answers the question "did this agent have permission to perform this action at that moment?". Detailed minimum-scope pattern in the cluster on [minimum permissions for AI agents: least authority applied](https://danilolapegna.com/guides/least-authority-ai-agents-italian-smb.html). **Input hash + redacted summary**. Hash of full input for integrity verification, plus redacted summary of content (e.g. "850-character customer email, contains personal data such as first and last name, source domain @example.com"). If full content is needed, link it to the independently controlled storage described above. **Output hash + redacted summary**. Record the output's hash and a summary with unnecessary data removed. Apply the same purpose, access and deletion rules used for the input. **Decision record**. The rule, route or reason code that selected the tool. Do not depend on the model's internal chain of thought: it may be unavailable, is not a stable artefact and may contain data you should not retain. **Outcome + latency**. Success/error/timeout, latency in ms. **Human-in-the-loop status**. If this action required a human gate, who approved, when, after how long. If the gate was bypassed, why. ## Reconstruct one sequence In a synthetic test, the model proposes sending a price list. Authorisation permits customer A only, the tool sends it and the external service confirms acceptance. Record proposal, authorisation and confirmation separately. If an HTTP 200 does not confirm the final outcome, mark that outcome unknown rather than inferring delivery. Repeat with a forbidden recipient: sending should be denied and recorded. The nine fields are a baseline, not a promise of complete reconstruction or automatic compliance. Measure volume on your traffic, rehearse an incident reconstruction and remove fields that do not serve the declared purpose. ## Storage: protect integrity, access and keys Make three storage decisions explicit. **Encryption and key management**. Use the platform's encryption controls and separate keys, permissions and data. The useful test is not whether a policy says “AES-256”; it is who can decrypt logs, how keys rotate and what happens when access is revoked. **Integrity and detectable tampering**. For logs used as evidence, prevent or expose unauthorised changes and deletion. Append-only storage, signatures, hash chains and object locks are different options: choose according to threat, duties and cost, then test recovery. **Indexed for the questions you will actually ask**. During an incident, a log you cannot query quickly is technically present but operationally weak. Start with trace ID, agent ID, timestamp and tool name, then test a real reconstruction question such as “all of the agent's actions during this window”. Measure the query time and set an internal target that matches the incident process. Cost depends on volume, payload size, retention, replication and the query engine. Run a representative traffic test and add a spend alert; without those inputs any “SMB price” is guesswork. ## Retention: the GDPR vs DORA puzzle The puzzle is explicit. GDPR requires minimisation and storage limitation. DORA requires financial entities to maintain resilience and incident-management/reporting processes; contracts may require suppliers to preserve useful evidence. Duration remains a reasoned decision, not a number automatically supplied by either rule. A practical way to resolve the tension is to separate retention tiers by log layer. Tier 1 (structured metadata): retain only the identifiers and outcomes needed for the documented period. Metadata may still be personal data; verify rather than assume. Tier 2 (content with unnecessary data removed): use independently managed storage for different retention rules. Another event in the same span is insufficient. Test both data removal and expiry deletion. Tier 3 (full debug payload): restrict access and keep it for the shortest period justified by the real need. If a hash, canary or redacted summary is enough, do not retain the payload. Tier 4 (full conversation transcripts for training/eval): avoid collection by default. Where necessary, define the lawful basis, notice, access, duration and any applicable objection or withdrawal rights. Consent is one possible basis, not a universal formula. The four-tier model makes the trade-off explicit and gives security, privacy and legal teams one decision to review. The broader operating model is in the [agentic-security guide](https://danilolapegna.com/guides/agentic-ai-security.html). ## An operating target for the first hour The first hour does not guarantee a root cause and does not replace legal deadlines. It should produce four things: containment, preserved evidence, an owner and an initial decision. **Step one: contain and annotate.** Stop the path causing harm: suspend the agent, revoke a credential or isolate a tool as the case requires. Record who changed what and when. Preserve snapshots and logs where safe, but do not keep compromised access active merely to leave the system untouched. **Step two: preserve and document.** Bound the time window, identify the traces and identities, and save the available configuration, retrieval results, tool calls and outputs. Do not expect or store internal chain of thought. Write a hypothesis separately from observed facts; [MITRE ATLAS](https://atlas.mitre.org/) can help classify the technique. The report should record timing, severity, systems, containment, known impact, gaps and next checks. **Step three: assign the decision.** Set further containment, the investigation owner, communications and regulatory triggers. If the organisation is a financial entity, activate the applicable DORA process; if personal data is involved, assess GDPR Article 33. Do not wait for a complete root cause before involving the decision owner. The first 60 minutes should produce something usable: containment, evidence preservation, an owner and an initial hypothesis. Logging does not promise root cause in an hour; it prevents the investigation from starting at zero. ## Logging pays when it answers a question My test for useful logs is a concrete reconstruction: which version, tool, permissions, outcome and approver? Try answering without opening full conversations. Remove unnecessary data and test the intended deletion. These records can support security, privacy and contractual duties, whose requirements remain distinct. --- To apply these checks, bring the workflow description, permissions and test results to the [AI agent control and security service](https://danilolapegna.com/services/hardening-controllo-agente-ai). Start with the first concrete gap and define how its correction will be tested. ## Frequently asked questions ### What should logs record to reconstruct an agent's actions? Record when the action happened, agent and system versions, related operations, tool and permissions, references to input and output, the authorisation rule, outcome, duration and any human approval. The guide organises these into nine groups to adapt to the questions your logs must answer. ### How can we reconstruct actions without retaining too much personal data? Separate metadata, redacted payloads, full payloads and transcripts. For each tier document purpose, lawful basis, access, duration, deletion and legal hold. Periods depend on the case; consent is not the only possible lawful basis, and a retention model alone does not make a system GDPR-compliant or DORA-ready. ### What are OpenTelemetry's conventions for AI operations? OpenTelemetry offers conventions for recording operations, models and errors. Check the adopted version. Span events do not guarantee independent retention: content with different rules needs storage that enforces them. ### What should the first hour of incident response achieve? Three initial steps: contain, preserve/document, decide. The first 60 minutes are an operating target, not a legal deadline. For financial entities, DORA classification and reporting sit across Articles 17-23; for personal data assess GDPR Article 33. Escalate promptly to the owner, DPO and legal team when scope is uncertain. ## Sources [OpenTelemetry · AI Agent Observability semantic conventions](https://opentelemetry.io/blog/2025/ai-agent-observability/) [MITRE ATLAS · Adversarial Threat Landscape for AI Systems](https://atlas.mitre.org/) [OWASP Top 10 for Agentic Applications 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) [Digital Operational Resilience Act (DORA) · official text](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) [GDPR · Regulation 2016/679 official text](https://eur-lex.europa.eu/eli/reg/2016/679/oj) [NIST SP 800-92 · Guide to Computer Security Log Management](https://csrc.nist.gov/publications/detail/sp/800-92/final) AI-assisted content, reviewed by a human.