Every other control in this series — runtime enforcement, default-deny scoping, provenance-aware policy, tiered human oversight — depends on a foundation most teams do not build until they need it for the first time: a complete, queryable, immutable record of what the agent actually did. The runtime policy that blocked a privileged action is only verifiable if the block was logged. The least-privilege scoping that constrains the agent is only auditable if every grant and every denial is captured. The prompt injection that hijacked the planner is only diagnosable if the content provenance was threaded through the decision trail. Without this layer, the rest of the security architecture is a set of claims rather than a set of facts. For the broader risk picture, this control sits within the OWASP Top 10 for Agentic Applications framework and is the foundation for detecting both cascading agent failures (ASI08) and rogue agent behavior (ASI10).
Why observability for agents is structurally different
Traditional application observability assumes the system does what its code says, mostly. Logs capture request and response, errors flag deviations from the happy path, and traces show the call graph across services. Agents break each of those assumptions. Their behavior is non-deterministic, so "what the code says" doesn't fully describe what the agent will do. Their failure modes are often latent — a successful action sequence today may have planted state that surfaces as a wrong action three steps and two days later. Their call graphs include tool invocations whose semantics the trace layer doesn't understand, and in multi-agent deployments, the graph spans agents that may not even share an observability backend. The implication is that the observability layer cannot be added after the fact and cannot rely solely on conventional APM. It has to be designed in, and it has to capture agentic semantics — reasoning, tool selection, policy decisions, inter-agent handoffs — not just HTTP-shaped requests and responses.
That visibility gap is the operational equivalent of the design-time gap that prompts this whole series: organizations are running production agents whose actions cannot be reconstructed after the fact, which means incidents cannot be diagnosed, compliance evidence cannot be produced, and the trust required for autonomous operation cannot be earned.
The four things every agent must log
Model Calls
Every call to a model, with the full prompt (including any retrieved context and tool outputs in the context window), model identity and version, parameters, and the returned output. The OpenTelemetry GenAI semantic conventions define a standard schema for this layer.
Tool Calls
Every tool invocation with the agent identity, parameters, response, and the policy decision that authorized it. Tool calls are where the agent affects the world — the action surface that incidents propagate through.
Content Provenance
For each input that influenced an action, the provenance label that source carried (user, retrieved document, tool output, agent peer). Without provenance threading, an indirect prompt injection incident cannot be traced back to the malicious content.
Inter-Agent Messages
Every message between agents, with sender and recipient identity, payload, and the re-authorization decision at the recipient. In multi-agent deployments this is the only way to detect cascade failures (ASI08) where an upstream agent's failure propagates to downstream agents.
Provenance threading is what makes the log forensically useful
An action log without provenance answers the question "what did the agent do?" but not the more important question "why did it do it?" The why is almost always the part that determines whether an incident was a model failure, a policy gap, an upstream content issue, or an attacker-introduced injection. Threading provenance through the log means that every action entry carries pointers to the content that motivated it, the policy decision that authorized it, and the provenance labels of every piece of context the model reasoned over. The principle is the same as that of provenance-aware policy enforcement: trust tier doesn't just gate the action in real time, it also annotates the audit trail so post-hoc investigation can ask "what trust tier of content was driving this action?" and get a defensible answer.
In practical terms, a forensically useful entry for a tool call looks like: agent identity, target tool and operation, parameters, response, the policy decision and the rule it matched, the model call that produced the request, the trust-tier labels of every input that influenced the model, and the resulting outcome. That entry alone is enough to reconstruct the local context of a single action; chained together across a session, it allows full reconstruction of an agent's reasoning path.
"The runtime policy that blocked a privileged action is only verifiable if the block was logged. Without the log, the security architecture is a set of claims rather than a set of facts."
Working through these controls yourself? The Skyrelis Agent Checklist condenses this series into a one-page pre-production reference.
Download Free →Anomaly detection on action sequences
Logs are the substrate; anomaly detection is what turns them into a defense. Agentic anomaly detection differs from traditional behavioral analytics in that the baseline is the agent's expected action distribution for its persona and task — not the user's historical pattern. An agent that suddenly attempts a tool call outside its persona's typical envelope, accesses a record outside its data scope, or produces an output that doesn't match the trust tier of its inputs is a signal worth alerting on regardless of whether the policy engine ultimately allowed or denied the action. The alert isn't about the action; it's about the drift.
| Signal Tier | Trigger | Response |
|---|---|---|
| Information | Routine action within persona envelope, allowed by policy | Log and proceed; surfaced in dashboards for trend analysis |
| Notice | Action outside typical envelope but within authorized scope; policy allowed with conditions | Log with alert flag; reviewed in next operational cycle; threshold tuning if recurring |
| Alert | Action denied by policy, attempted privileged operation outside scope, content from low-trust source motivating a privileged action, or pattern matching known compromise indicators | Real-time alert to security; agent session optionally suspended; human review required before continuation |
The tiering mirrors the human-oversight tiering described in our guardrails piece, and for the same reason: not every signal warrants the same response, and operational fatigue from low-quality alerts is itself a failure mode.
Multi-agent tracing
In a single-agent deployment, the audit log is local to one runtime. In multi-agent deployments, the actions that matter most often span agents — an upstream planner hands off to a downstream executor, which calls a tool that returns content to a third agent, which makes a decision based on it. Tracing across that chain requires propagating a correlation identifier through every inter-agent message, every tool call, and every policy decision, and aggregating the resulting traces in a way that lets a security analyst reconstruct the full chain after the fact. The OpenTelemetry GenAI specification defines spans and conventions for this; the operational requirement is that every agent in the deployment emits compatible spans and that the trace backend can join them.
Without multi-agent tracing, cascading agent failures (ASI08) are detected by their downstream consequences rather than at the point of cascade origin. By the time a wrong outbound action is observed, the original failure may be several agent hops upstream and hours in the past. Tracing closes the loop between symptom and root cause.
Forensic readiness and compliance evidence
The audit infrastructure built for security operations doubles as compliance evidence with very little additional work, because the same primitives the security team needs — immutable logs, action attribution, policy decision records, retention against tampering — are exactly what regulators ask for. The EU AI Act's high-risk system obligations, fully in force August 2026, require logs "sufficient to reconstruct the decisions of the AI system" with retention bounds appropriate to the risk profile. The NIST AI Risk Management Framework's Measure and Manage functions both require continuous observability with documented retention. SOC 2 Type II audits in regulated verticals are increasingly asking for agent-specific action evidence, and the simplest way to provide it is from the same log store that powers operational monitoring. For a full mapping of agent controls to EU AI Act, NIST AI RMF, SOC 2, and ISO 27001, see Compliance Controls for AI Agents. Anomaly detection on agent behavior is also the primary signal for shadow and rogue agent detection, and multi-agent tracing is the foundation for securing multi-agent workflows.
The relationship to runtime enforcement
Audit and monitoring are not optional add-ons to runtime enforcement — they are what makes runtime enforcement operable. A policy decision point that returns allow/deny without logging is opaque; nobody can verify it worked, nobody can debug it when it didn't, and the regulator who shows up six months later will not accept "trust us, the policy was enforced" as evidence. The same is true in reverse: an audit infrastructure that records what happened without a runtime decision layer to act on it is forensically interesting but operationally toothless. The two compose into a single picture: runtime policy decides, the action log records, anomaly detection alerts, and forensics reconstructs — each layer feeding the next. This is also the architecture that makes least-privilege scoping verifiable in production.
Pre-Production Audit and Monitoring Checklist
Frequently Asked Questions
Standard application performance monitoring captures HTTP-shaped traffic, errors, and traces across services — it was built on the assumption that the application does what its code specifies. Agents add three properties APM was not designed for: non-deterministic behavior, agentic-semantic actions (model calls, tool selections, policy decisions) that APM's span model doesn't understand natively, and latent failure modes where a successful action sequence today may surface as a wrong action much later. The OpenTelemetry GenAI semantic conventions extend the OTel model with agentic primitives precisely because the base specification didn't capture them.
Content provenance is the label attached to each piece of text in the agent's context, identifying where that text came from — the user, a retrieved document, a specific tool, an agent peer. The prompt injection chapter describes why provenance matters at policy time. The audit chapter is about why provenance matters at investigation time: when an incident occurs, the question "what content motivated this action?" is what determines whether the failure was a model issue, a policy gap, or an attacker-introduced injection.
User and entity behavior analytics builds baselines from human or service patterns. Agent behavior analytics builds baselines from the agent persona and task — what tools agents of this persona typically invoke, what data scopes they typically touch, what the trust-tier distribution of their inputs typically looks like. The most useful signals are typically not statistical outliers per se — they are content-driven anomalies, such as an agent attempting a privileged operation motivated by content from a low-trust source.
For high-risk AI systems, the EU AI Act requires automatic logging that is "sufficient to ensure a level of traceability of the AI system's functioning that is appropriate to the intended purpose," retained for at least six months by default and longer where applicable law requires. In practice for agentic systems, this means every action that affects the world or affects a person needs to be reconstructable from the log — the model output, the policy decision, the data accessed, the action taken, and enough context to explain why.
Usually no. The retention and tamper-evidence requirements for AI agent audit logs are stricter than the operational requirements for application logs. The access patterns also differ: application logs are queried operationally and rotated aggressively; audit logs are queried during investigations and audits. The common architecture is to instrument once (OpenTelemetry with the GenAI semantic conventions is the de facto standard), then tee the relevant streams into an immutable audit store with appropriate retention and access controls.
See how Skyrelis makes every agent action auditable
Provenance-threaded action logs, anomaly detection, multi-agent tracing, and compliance evidence — in one runtime layer.