Teams often assume standardised telemetry is automatically safe because it improves interoperability. In practice, standardisation can widen exposure if sensitive AI traces are broadly readable or exported into multiple backends. The control question is whether access policies, classification, and retention rules were defined before instrumentation was scaled.
Why This Matters for Security Teams
OpenTelemetry is often introduced as an observability standard, but in AI environments it becomes a data movement decision as much as an engineering one. Traces, spans, prompts, retrieved context, tool calls, and model outputs can all contain secrets, personal data, or attack-relevant operational detail. The risk is not the telemetry format itself. The risk is that teams instrument first and govern later, which can turn a useful diagnostic layer into a broad disclosure channel.
Security teams also tend to underestimate how quickly AI telemetry spreads across systems. One dataset may be ingested by APM tools, logs, SIEM, ticketing platforms, and developer dashboards. That is why the control conversation should begin with classification, access boundaries, and retention, not just collector configuration. The NIST Cybersecurity Framework 2.0 is useful here because it frames visibility, governance, and risk treatment as operational controls rather than optional documentation.
Practitioners also miss the AI-specific blast radius. A trace that records prompt templates, system instructions, retrieval results, or tool inputs can reveal guardrail logic, data sources, and even prompt injection artifacts that attackers can reuse. In practice, many security teams encounter telemetry exposure only after a debugging export, support bundle, or shared dashboard has already replicated sensitive AI context into places it was never meant to reach.
How It Works in Practice
OpenTelemetry works by emitting standardised signals from applications and services into collectors, processors, and downstream backends. In AI systems, that often includes request spans around inference calls, tags for model versions, latency metrics, and structured logs for tool execution. The challenge is that AI workloads generate higher-risk fields than conventional services, especially when developers capture prompts, chain-of-thought-like debugging notes, retrieved documents, or output samples for troubleshooting.
Effective deployment starts with data minimisation. Security and platform teams should decide what must be captured for performance and incident response, then suppress or redact everything else. Access should be segmented so that developers, SRE teams, and security analysts do not automatically inherit the same telemetry visibility. Retention should be shorter for high-risk AI traces, and export paths should be documented so sensitive data does not silently replicate into every observability backend.
- Classify AI telemetry fields before instrumentation, including prompts, retrieval context, and tool arguments.
- Redact secrets, personal data, and high-risk model inputs at the collector or processor layer.
- Restrict read access to AI traces by role and purpose, not by broad environment membership.
- Align telemetry retention with investigation needs, legal hold, and data minimisation obligations.
- Test whether support exports, debug mode, and shared dashboards leak model context outside approved boundaries.
This is also where AI governance and detection intersect. If trace data is used to monitor prompt injection, model misuse, or suspicious tool activity, that visibility must be balanced against the risk of storing the very content you are trying to defend. Guidance from OWASP Top 10 for Large Language Model Applications and the NIST AI Risk Management Framework supports this approach by treating logging, monitoring, and provenance as part of the system’s safety posture, not an afterthought.
These controls tend to break down when teams enable verbose tracing across distributed agent workflows because sensitive context is duplicated into multiple collectors faster than policy can keep up.
Common Variations and Edge Cases
Tighter telemetry controls often increase operational overhead, requiring organisations to balance debugging depth against privacy, cost, and incident response speed. That tradeoff becomes sharper in agentic ai, where an agent may chain several tool calls and each step can produce useful but sensitive trace material. There is no universal standard for how much prompt or retrieval content should be retained, so current guidance suggests choosing the minimum data needed for a specific operational purpose.
Some environments can safely store richer traces, but only under stronger controls such as separate security projects, privileged analyst access, and short retention windows. In regulated contexts, telemetry may also become evidence, which means tamper resistance and auditability matter as much as redaction. For teams building GenAI services, the NIST AI Risk Management Framework and OWASP Agentic AI Top 10 are useful references for aligning observability with model governance and agent safety.
The edge case that often gets missed is multi-tenant or shared-platform AI infrastructure, where one application team’s telemetry settings affect many services at once. Another is incident response, where analysts need enough detail to reconstruct malicious behaviour without permanently exposing the underlying content. Best practice is evolving, but the safer pattern is to treat AI telemetry as controlled security data rather than generic engineering noise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Telemetry governance needs risk ownership before data is broadly exported. |
| NIST AI RMF | AI RMF addresses monitoring, measurement, and governance of AI system risk. | |
| OWASP Agentic AI Top 10 | Agentic AI traces can expose tool use, prompts, and control logic. | |
| OWASP Non-Human Identity Top 10 | Telemetry often includes service credentials and non-human identity context. | |
| MITRE ATLAS | ATLAS helps map prompt injection and inference abuse visible in telemetry. |
Use telemetry to detect AI attack patterns without storing unnecessary sensitive content.
