AI Agent and LLM Observability Buyer's Guide

Teams buying AI agent and LLM observability tools often discover after deployment that the product shows pretty traces of model calls but cannot answer the questions security and audit actually ask: which agent did this, under whose authority, with which tool, and what data left the building. The market now spans LLM tracing platforms, evaluation and prompt management suites, AI gateways with logging, and extensions to existing application performance monitoring (APM) and SIEM products. This vendor-neutral buyer's guide explains what the category does, when you need a dedicated product, the capabilities that separate a debugging tool from an operational and security control, and how to run a proof of concept against your own agents. It is for platform engineers, security architects and procurement leads. The telemetry model itself (spans, attributes, content capture) is covered in the LLM Observability Guide, which this page does not repeat.

Key takeaways

Buy for agents, not single prompts. A multi-step agent run needs one trace that links planning, every model call, every tool and MCP call and every sub-agent hand-off, keyed to a stable agent identity.
Insist on open telemetry. Products that ingest and export OpenTelemetry (OTLP) using the GenAI semantic conventions keep you portable; proprietary SDKs alone create lock-in for your most sensitive data.
Content capture is the main risk you are buying. Prompts, tool arguments and outputs are opt-in in the conventions for a reason: the tool becomes a store of personal data and secrets, so redaction, access control and retention must be evaluated as hard requirements.
Identity attribution decides security value. If a trace cannot tell you the agent ID, the human or workload it acted for and the credential it used, the product helps developers but not your SOC or auditors.
Prove it on your own agents. A two to four week proof of concept with real frameworks, a scripted prompt injection and a cost runaway test shows more than any demo.

What the category does

AI agent and LLM observability products collect, store and analyse telemetry from applications that call large language models and from agents that plan and act with tools. Products differ mostly in where they started, which shapes their strengths.

Product type	Typical strengths	Typical gaps for security and audit
LLM tracing and evaluation platforms	Deep trace views of prompts, completions and tool steps; prompt versioning; offline and online evaluations; datasets for regression tests	Often weak on tamper evidence, long retention, SIEM export and identity context beyond a user ID field
APM and observability suites with GenAI support	Correlate model calls with the rest of the service (latency, errors, infrastructure); mature RBAC, retention and alerting	Quality evaluation and agent-specific views can be thinner; content capture may be off or coarse
AI gateways and proxies with logging	Central capture of every model call regardless of framework; per-key cost and rate controls; policy enforcement point	See only model traffic, not internal tool execution or local agent steps, unless agents route tools through the gateway
Agent platform native tracing (cloud agent services, agent frameworks)	Zero-effort traces for agents built on that platform	Limited to that platform; multi-cloud or multi-framework estates end up with several silos
SIEM and security analytics extensions	Detection rules, case management, long retention, correlation with identity and endpoint logs	Usually depend on another layer to produce structured agent telemetry first

Most estates combine two of these: an engineering-facing tracing or APM tool and a security-facing pipeline into the SIEM. The buying decision is which one is the system of record for agent activity. See the AI Gateway and LLM Gateway Guide for the gateway pattern.

When you need it

Agents act with real permissions: once an agent can write to a ticketing system, send email, run code or call internal APIs, you need a reconstructable record of each action. Incident responders will ask for it first; see the AI Agent Observability and Incident Response Guide.
More than one framework or provider: a single team on one framework can live with that framework's console. Several teams, models and clouds need a common schema.
Cost or reliability incidents: runaway loops and retry storms are OWASP LLM10 Unbounded Consumption in practice, and you cannot cap what you cannot measure per agent and per key.
Regulated use: the EU AI Act requires high-risk AI systems to allow automatic recording of events (Article 12), and deployers to keep logs under their control for at least six months unless other law requires otherwise (Article 26(6)). The application dates for these obligations have been amended; check the current text before relying on a date. See the AI Agent Audit Trails for Regulators Guide.
Quality must be shown, not asserted: if business owners need evidence that answers stay accurate after model or prompt changes, you need evaluation tied to production traces.

Small organisations running one or two internal assistants can often start with an open source tracing tool or their existing APM's GenAI support plus gateway logs. Large organisations with dozens of agent teams should treat this as a platform purchase with a central schema, data protection review and SIEM integration from day one.

Must-have capabilities

Telemetry coverage

Agent spans: support for the OpenTelemetry GenAI agent operations, including invoke_agent, execute_tool, create_agent and invoke_workflow, with parent and child relationships preserved across sub-agents. The conventions are published in the open-telemetry/semantic-conventions-genai repository and are still at Development status (checked 28 October 2026), so ask how the vendor handles renamed attributes.
Agent and session identity: gen_ai.agent.id, gen_ai.agent.name, gen_ai.agent.version and gen_ai.conversation.id captured and searchable, not buried in free-text metadata.
Tool and MCP visibility: gen_ai.tool.name, gen_ai.tool.call.id, and for MCP the mcp.method.name and mcp.session.id attributes, so a tool call can be joined to the MCP server log on the other side.
Metrics: gen_ai.client.operation.duration, gen_ai.invoke_agent.duration, gen_ai.invoke_agent.tool_calls, gen_ai.execute_tool.duration and the token usage metrics, broken down by agent, model and API key.

Data protection

Content capture controls: per-application switches for prompt, output, system instruction and tool argument capture (all opt-in in the conventions), with sampling.
Redaction before storage: pattern and entity-based masking applied in the SDK or collector, not only at display time, covering secrets and API keys as well as personal data.
Access and retention: SSO, role-based access that separates metadata viewers from content viewers, per-project retention and deletion that meets data subject requests.

Security and audit

Identity context: the human principal, the workload or agent identity and the credential or token reference for each action. See the Agent Identity and Access Guide.
Integrity and export: immutable or append-only storage options, export to SIEM in a documented format, and an audit log of who viewed or exported traces (NIST SP 800-53 AU-9).
Detection hooks: alerting on tool calls to new destinations, tool-call counts per run above a threshold, guardrail or policy denials and spend anomalies.

Quality and evaluation

Online and offline evaluation: scoring of production traces and regression suites before release, with results linked to prompt and model versions.
Human review queues: annotation workflows that respect the same content access rules as traces.

Evaluation criteria

Criterion	Weight (suggested)	What good looks like	How to test
Open standards	High	Native OTLP ingest and export; GenAI semantic conventions mapped, not translated into a closed schema	Send traces from an OpenTelemetry collector; export them back out and diff attributes
Agent trace fidelity	High	Full tree for multi-agent runs, including async tools and retries	Run a three-level agent with parallel tool calls and check nothing is orphaned
Identity attribution	High	Agent ID, delegating user, workload identity and key reference on each span	Ask the tool "show every action by agent X for user Y last week"
Redaction and privacy	High	Masking before persistence; content off by default; region choice	Seed fake card numbers, emails and an API key; confirm none is stored
Security integration	Medium to high	Streaming SIEM export, webhooks, documented schema, viewer audit log	Build one detection in your SIEM from exported data
Evaluation depth	Medium	Custom evaluators, datasets from traces, version comparison	Score a prompt change against 200 historical traces
Cost visibility	Medium	Spend per agent, model, key and tenant with budgets and alerts	Trigger a deliberate loop and time the alert
Deployment model	Context dependent	SaaS, single-tenant or self-hosted options; clear data processing terms	Review the DPA, sub-processors and residency options
Scale and price model	Context dependent	Predictable pricing by spans, events or hosts; sampling that does not break traces	Model one month of production volume with the vendor's calculator

Use the Buyer's Guide Methodology and Scoring Template to turn these into a weighted score.

Questions to ask vendors

Which OpenTelemetry GenAI semantic convention version do you support today, and how do you handle attribute renames while the conventions remain at Development status?
Can we ingest from any OpenTelemetry SDK or collector without your proprietary SDK, and export all stored data in OTLP or another documented format?
Where is content redacted: in the SDK, in a collector, at ingest, or only in the user interface?
Can metadata be retained longer than prompt and output content, with separate access roles for each?
How do you represent the agent identity, the delegating human and the credential used for a tool call?
Do you trace MCP client and server operations, and can we join a tool span to the MCP server's own log?
What evidence of integrity do you provide (append-only storage, hashing, viewer and export audit logs)?
How are API keys and ingestion tokens for your service scoped, rotated and revoked? Can they be workload-identity based?
Where is data processed and stored, which sub-processors see trace content, and is customer data used to train any model, including your own evaluation models?
What happens to traces when an LLM-as-judge evaluator is used: which model sees the content and under what terms?

Red flags

Proprietary-only instrumentation: no OTLP ingest or export means your history is stranded if you leave.
Content captured by default: full prompts and tool outputs stored with no masking and one access role.
Identity as a free-text tag: "user" is a string the developer sets; there is no field for agent or workload identity.
Sampling that splits traces: head sampling that drops child spans of a sampled run, leaving gaps in exactly the runs you need to investigate.
Long-lived shared ingestion keys: a single project key embedded in every agent, with no rotation story. That key can also be used to inject false telemetry.
Evaluation via undisclosed third-party models: traces sent to another provider for scoring without it being in the data processing terms.

Deployment and integration

Define the schema first. Agree mandatory attributes for every agent: agent ID and version, owner team, delegating principal, environment, model and gateway key reference. Put it in your platform standard.
Instrument through a collector. Route SDK telemetry through an OpenTelemetry collector you control, apply redaction and tail sampling there, then fan out to the observability product and the SIEM. This keeps one control point.
Start with metadata only. Turn on content capture per application after a data protection review, with masking tested on seeded data.
Connect the gateway. If you use an AI gateway, propagate trace context through it so gateway logs and agent traces share a trace ID.
Wire security use cases. Export tool-call and policy-denial events to the SIEM and build the first detections (new tool destination, tool-call count spike, spend anomaly). See the Agent Controls and Monitoring Guide.
Set retention by data class. Keep metadata as long as audit and AI Act obligations need (Article 26(6) sets at least six months for deployers of high-risk systems), and keep content for the shortest useful period.
Plan the exit. Test a full export before signing a multi-year term, and keep the collector configuration vendor-neutral so switching is a routing change.

Treat the observability product itself as a non-human identity consumer and holder: its ingestion keys, SIEM export credentials and any model API keys used for evaluation belong in your secrets manager with owners and rotation. See the LLM API Key Security Guide.

Pitfalls

Debugging tool bought as a security control: engineering adopts a tracing tool, and security later finds no export, no retention control and no identity fields. Involve the SOC in requirements.
Instrumenting the model call but not the tool: in the Sentry MCP agentjacking research, coding agents read a planted error report through an MCP server and ran an attacker-chosen command with the developer's credentials, and each step looked legitimate to conventional controls. Only tool-level and command-level telemetry linked to the content source shows that chain.
Trace store as a new data lake of secrets: tool arguments routinely contain tokens and connection strings. Without masking, the observability tool becomes a target (OWASP LLM02 Sensitive Information Disclosure).
One silo per framework: each team uses its framework's native console and nobody can see cross-agent activity.
No baseline: alerts on tool-call volume or spend are noise without a few weeks of per-agent baselines.

Proof of concept

Pick two real agents on different frameworks or providers, one of which uses MCP tools.
Instrument both through your own OpenTelemetry collector, metadata only, and confirm complete traces for 50 runs each.
Enable content capture on a test copy, seed synthetic personal data and a fake API key, and verify masking in storage, search and export.
Run a scripted indirect prompt injection (a benign marker instruction planted in a retrieved document) and check you can trace it from the source document to the tool call it caused (MITRE ATLAS AML.T0051 LLM Prompt Injection, AML.T0053 AI Agent Tool Invocation).
Run a controlled loop to exceed a cost threshold and measure time to alert.
Export one week of data to your SIEM and build two detections from it.
Answer three audit questions from the tool alone: all actions by one agent, all agents acting for one user, and every external destination contacted in a day.
Score results against the evaluation criteria table and record gaps as contract conditions.

Buyer checklist

Requirements signed off by engineering, security, privacy and audit.
OTLP ingest and export confirmed; GenAI convention version documented.
Agent ID, delegating principal and credential reference present on tool spans.
Redaction proven on seeded data before any production content capture.
Separate roles and retention for metadata and content.
SIEM export live with at least two detections.
Ingestion and export keys stored in a secrets manager with an owner and rotation.
Data processing terms cover evaluators, sub-processors and residency.
Full data export tested before contract signature.

Framework mapping

Framework	Reference	Relevance to the purchase
NIST SP 800-53 Rev. 5	AU-2, AU-3, AU-12	Which agent events are logged and what each record contains
NIST SP 800-53 Rev. 5	AU-6, SI-4	Review, analysis and monitoring of agent activity
NIST SP 800-53 Rev. 5	AU-9, AU-11	Protection and retention of trace data
NIST CSF 2.0	DE.CM-09, DE.AE-02	Monitoring runtime environments and analysing adverse events
NIST CSF 2.0	GV.SC-07	Assessing the observability vendor as a supplier that holds sensitive data
OWASP Top 10 for LLM Applications 2025	LLM02, LLM06, LLM10	Sensitive data in traces, excessive agency, unbounded consumption
EU AI Act	Articles 12 and 26(6)	Automatic event logging and deployer log retention for high-risk systems

Standards and references

How NHI Mgmt Group can help

We provide independent advice on agentic AI identity, monitoring and tool evaluation. Browse vendors in our products directory or contact us.

AI Agent and LLM Observability Buyer’s Guide: Choosing Tracing, Evaluation and Audit Tools