Summary: The one control every framework in this vault independently requires, and the precondition for detection, response, forensics and regulatory compliance alike — plus the reasons it is harder for AI systems than for anything else.
Sources: raw/MITRE-ATLAS/AML.M0024-*.md; raw/AI-incident-response/; raw/Agentic/Agentic-AI-Threats-and-Mitigations-1.1.pdf; raw/AI-regulations/Regulation - EU - 2024_1689.md; raw/Supply-chain-attacks/; raw/Agentic/Security Monitoring for AI Agents and MCP.md; raw/Agentic/Agentic AI Threat Modeling Framework_ MAESTRO.md
Last updated: 2026-07-30
Five independent sources converge
No other control in this corpus is demanded by every framework. This one is:
| Source | Requirement |
|---|---|
ATLAS AML.M0024 AI Telemetry Logging | Recurs across detection-oriented mappings; “telemetry logging can help identify if unsafe prompts have been submitted to the LLM” |
| CoSAI | Preparation phase requires capturing “prompt logs, model inference activity, tool executions, and memory state changes” |
| Microsoft | Names telemetry gaps as one of four properties that break traditional IR for AI |
| OWASP ASI | Cryptographic logging and immutable audit trails in Playbooks 1, 5; forensic tool-interaction logging in 3; inter-agent communication logging in 6; T8 exists as a threat because logging fails |
| AI Act Art 12 | Legally mandates automatic event logging over the system’s lifetime for high-risk systems |
Four of the five were built by different communities with different goals. That is the strongest agreement signal the vault contains — stronger than any agreement between the four attack taxonomies.
A sixth was added on 2026-07-30 and it is a different kind of source: Realm Security supplies a field-level schema and working code rather than a requirement. Every source above says log; that one says what a log line contains. See below.
And a seventh says the log is a target. MAESTRO’s Layer 5 names poisoning observability data, compromising monitoring tools “to hide malicious behaviour”, data leakage through observability, and DoS against evaluation infrastructure. Three of its six Layer 5 threats attack visibility itself — which makes the immutability requirement below load-bearing rather than best practice.
Why it is load-bearing
Everything downstream depends on it:
- Detection — anomaly detection, drift monitoring and trust scoring all consume telemetry. Without it they have nothing to run on.
- Response — containment decisions (“roll back the model? purge memory? rebuild the vector store?”) are unanswerable without knowing what was touched.
- Forensics — detection cannot reliably distinguish attack from drift. Lineage lets you reconstruct afterwards what no detector could classify at the time. This is the single strongest argument for investing here.
- Compliance — Art 12 for high-risk systems; the reporting clocks in AI incident response cannot be met without a record.
What to log for an AI system
Beyond conventional application telemetry, drawn from CoSAI and ASI:
- Prompt logs — inputs, including retrieved context, not just user text
- Model inference activity — and classifier confidence, which Microsoft names specifically since “standard security monitoring doesn’t capture… classifier confidence shifts”
- Tool executions — every invocation, arguments included; ASI wants “forensic traceability”
- Memory state changes — reads, writes, and who or what authored each write
- Inter-agent communication — every agent-to-agent message in a multi-agent system
- Human overrides — ASI wants these logged and the reviewer patterns analysed for bias or misalignment
- Provenance metadata — lineage of datasets, weights and prompt templates
Two agentic additions that conventional logging never needs:
Source attribution on memory writes. ASI Playbook 2 requires “source attribution for memory updates. Enforce tracking of where AI knowledge originates.” Without it, memory poisoning is unattributable after the fact.
Knowledge lineage. “Maintain historical references of how AI knowledge evolved, allowing for forensic investigations into misinformation spread.” The only control that lets you find a cascade’s origin and roll back everything downstream of it.
A concrete schema
The vault’s one field-level answer, from the Realm source. Nine core fields, of which four carry the security weight:
| Field | Why it matters |
|---|---|
principal_user_id | On whose authority the agent acted. A tool call with no principal cannot be checked against that principal’s rights after the fact |
event_correlation_id | Makes the task the unit of investigation instead of the log line — one ID spans the agent’s own actions and every tool call across every MCP server |
agent_id vs agent_name | Instance versus role, so one misbehaving agent is separable from its fleet |
source_mcp_server | Attributes an action to the server that offered the tool — the field that identifies a poisoned tool provider |
Plus timestamp, log_level, message, model_id, event_action.
The mechanism is MCP client-side logging: tools emit through the server’s Context object, the agent registers a callback, and the agent stamps identity onto every received message. This is what makes one unified stream possible “instead of having to stitch the logs together after the fact” — which is the difference between an audit trail and a reconstruction.
Treat it as a floor, and note what it lacks. No tool arguments, no prompt, no model reasoning — the three places an injection payload actually appears. A log recording that get_url_reputation was called but not with what cannot reconstruct an attack. And the post calls its trail “immutable” while nothing in the code signs, chains or write-protects anything: immutability is asserted, not implemented. Against MAESTRO’s Layer 5 threats above, that gap is the whole control.
Cross-reference the field list against the “what to log” list above and the mismatch is instructive — CoSAI and ASI ask for prompt logs, memory state changes and inter-agent messages; the schema covers none of the three. The corpus’s only concrete schema is a subset of what the corpus’s frameworks require.
Why it is harder here
Volume and non-determinism. Microsoft: “A gap in a safety classifier can produce thousands of harmful outputs before any reviewer sees the first one.” The log is large, and the same input does not reproduce the same output — so replay-based verification, the normal way of confirming a fix, does not work.
Logs are an attack surface. Two ways:
- Poisoning — T5 Scenario 1 has misinformation accumulating in long-term memory and logs, so future retrieval reinforces it.
- Erasure — ASI’s T8 scenarios have attackers exploiting logging weaknesses so unauthorised transactions are “incompletely recorded or omitted,” and the RPA example has an attacker using prompt injection against a logging agent to remove records.
This is why both ASI and ATLAS specify cryptographic signing and immutability, not merely logging. An append-only signed log is a materially different control from a log.
Privacy tension. Microsoft flags it explicitly. Prompt logs contain whatever users typed, which for enterprise copilots is company-confidential and for consumer systems is personal data. The control that makes forensics possible also creates a disclosure liability, and no source here resolves it — Art 12 mandates the logging regardless.
Instrumentation point. The practical answer from the application layer: an AI gateway as a security control plane gives you one chokepoint across providers to instrument. Without a chokepoint, telemetry has to be built into every call site and will be incomplete.
The gap this creates
Telemetry is necessary and not sufficient, and the corpus is thin on what to do with it. ATLAS maps AML.M0024 to detection; ASI asks for anomaly detection, trust-score deviation tracking and decision-consistency monitoring without specifying any of them; the detectors that would consume all this are exactly the ones that cannot separate attack from drift.
The defensible position is to log for reconstruction first and detection second. Reconstruction works; detection is aspirational.
The 2026-07-30 sources sharpen this rather than closing it. The Realm post builds the telemetry and stops short of any alert logic — the detections listed on that page are this wiki’s inference, not the source’s. A SIEM rule set for agent logs remains the clearest missing artefact in the corpus.
One reason to log for reconstruction is now measured rather than argued: context poisoning happens with no attacker at all, continuously, in any long-running agent. So detection keyed on “the context contains something false” will fire constantly and mean nothing. Detection has to key on provenance — where content entered from — not on falsity. That is an argument for the source-attribution and lineage fields above, and against any detector that evaluates content on its merits.
Related pages
- control-catalogue — Tier 1
- defense-in-depth — telemetry cuts across layers 3–6
- where-defenses-fail — why reconstruction beats detection
- ATLAS mitigations —
AML.M0024 - Microsoft IR readiness
- CoSAI framework
- AI Act Art 12