Default telemetry can create a second identity record outside the IAM stack, one that correlates users, tenants, accounts, and behaviour across systems. That breaks data minimisation, complicates privacy reviews, and expands the blast radius of any log exposure. It also makes agent governance harder because visibility and overcollection become the same control surface.
Why This Matters for Security Teams
When AI agent telemetry starts capturing identity data by default, the log stream stops being neutral observability and becomes a parallel identity system. That matters because identity data in telemetry can correlate people, tenants, tokens, workspaces, and tool calls across environments, which expands exposure far beyond the original control plane. Guidance from the NIST AI Risk Management Framework and OWASP Agentic AI Top 10 both point to the same operational problem: visibility without minimisation creates new attack paths.
NHI Management Group has shown how often identity sprawl already outpaces governance in production environments, especially where service accounts and secrets are poorly tracked. The Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which means telemetry can easily become the first place sensitive identity evidence is concentrated rather than the last. That is especially risky for agentic systems, where logs often capture prompts, decisions, tool invocations, and linked identities in one record. In practice, many security teams discover the problem only after a log platform, analytics sink, or support export has already turned routine telemetry into a high-value identity repository.
How It Works in Practice
The core failure is not logging itself. It is logging identity-bearing fields without a strict purpose, retention, and access model. In agentic environments, telemetry often includes user IDs, tenant IDs, service account names, session tokens, correlation IDs, and tool payloads. Once those fields are copied into observability, they can outlive the session that created them and become queryable by analysts, developers, vendors, or incident responders who never needed direct IAM access.
Current guidance suggests treating agent telemetry as security data with privacy impact, not just operational data. The practical pattern is to separate what is needed for debugging from what is needed for attribution:
- Redact or tokenize identity fields before export wherever possible.
- Use pseudonymous correlation identifiers instead of direct usernames or account IDs.
- Restrict raw telemetry access with role-based controls and short retention windows.
- Keep the authoritative identity record in IAM, not in log storage or APM tools.
- Apply policy checks at collection time so agent traces only include approved fields.
For agent governance, this aligns with the broader direction described in the OWASP NHI Top 10 and the CSA MAESTRO agentic AI threat modeling framework: observability must not create a second, less governed identity surface. These controls tend to break down when telemetry is exported across multiple vendors and environments because field-level redaction and retention rules drift between systems.
Common Variations and Edge Cases
Tighter telemetry controls often increase operational overhead, requiring organisations to balance forensic depth against privacy, cost, and engineering friction. That tradeoff is real, especially when incident responders want full replayability and platform teams want broad observability. Best practice is evolving, but there is no universal standard for this yet, so the safest approach is to classify identity data in telemetry by sensitivity and business need, then only retain the minimum required for each class.
Edge cases matter. In multi-tenant agent platforms, tenant identifiers can be just as sensitive as usernames because they reveal customer structure and cross-account relationships. In support workflows, copied traces can accidentally include secrets, session context, or delegated access paths. In regulated environments, raw traces may also trigger records-management or data residency obligations. NHI Management Group’s research on the 52 NHI Breaches Analysis reinforces a recurring pattern: once identity-related artefacts spread outside the original control plane, containment becomes much harder.
For teams operating AI agents, the practical rule is simple: if a telemetry field would be harmful if exposed in a breach, it should not be exported by default. Use the NIST AI Risk Management Framework to justify minimisation decisions, and reserve raw identity-linked traces for narrowly scoped, time-bound investigations only.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | NHI-01 | Identity-bearing telemetry can become an ungoverned agent surface. |
| CSA MAESTRO | GOV-03 | Telemetry governance is part of agent trust, privacy, and containment. |
| NIST AI RMF | GOVERN | AI RMF governs risk decisions for collection, retention, and access to identity data. |
| OWASP Non-Human Identity Top 10 | NHI-06 | Logs that store identities can duplicate and expose NHI credentials or references. |
| NIST CSF 2.0 | PR.DS-5 | Data minimisation and protection apply directly to telemetry content. |
Minimise agent logs and strip identity fields before telemetry leaves the trusted boundary.
Related resources from NHI Mgmt Group
- What is the difference between prompt injection risk and identity abuse in agents?
- What breaks when AI agents are allowed to touch production data during integration work?
- What breaks when data governance is used as a substitute for AI agent identity controls?
- What breaks when AI agent data access is not tied to identity governance?
