High-cardinality labels turn metrics into expensive, fragmented data that is difficult to aggregate or alert on. When agents use values like user IDs, order IDs, raw paths, or dynamic error text as labels, the metric stops behaving like an operational signal and starts behaving like request storage. That undermines incident response and SLO tracking.
Why high-cardinality labels stop behaving like metrics
Metrics work best when many events collapse into a small, stable set of time series. High-cardinality labels break that compression. If an agent stamps a metric with a unique user ID, order ID, raw URL path, or free-form error text, each variation creates a new series, so the signal becomes fragmented, expensive to store, and slow to query.
The problem is not just cost. A metric with thousands or millions of one-off label combinations stops representing system health and starts representing event detail. That makes the series harder to compare over time, harder to aggregate across instances, and less reliable for alert thresholds or SLO calculations, because the thing you want to measure is no longer concentrated in a few durable buckets.
Why agent-generated telemetry makes the problem worse
Agents are particularly prone to emitting high-cardinality labels because they operate at runtime, encounter many paths, and often copy rich context into telemetry without restraint. An agent may treat anything it sees as useful metadata, but operational metrics need the opposite: a controlled vocabulary, low-dimensional labels, and stable dimensions that support grouping.
This is why agent telemetry should separate agent observability from raw request detail. The right design keeps metrics coarse and predictable, then sends trace IDs, request IDs, or full event context to logs or traces where high detail is expected. That preserves the metric as an operational signal instead of turning it into a storage index for every unique request.
It also matters when an agent’s label choices reflect per-action authorization boundaries or tool usage. If every tool invocation, path, or exception text becomes a label, the telemetry model becomes unstable exactly where the system is most dynamic. Stable labels should describe the class of action, not the exact object acted on.
What to change in telemetry design so agents remain measurable
The practical fix is to design metrics around bounded dimensions that answer the question you actually want to ask. Good labels usually describe environment, service, operation type, outcome class, or agent role. Bad labels usually expose IDs, raw inputs, dynamic paths, stack traces, prompts, and error strings that can change on every request.
When a metric needs investigative depth, route the detail to logs or traces and keep the metric label set small. That gives you both layers: aggregated trend visibility from metrics and forensic richness from event data. If an agent can generate unbounded label values, treat that as a telemetry design defect, not as a clever way to add context.
For broader agent programmes, a useful pattern is to enforce telemetry contracts the same way you enforce tool permissions. Agentic AI security guidance should treat observability as part of the control plane: define allowed labels, cap accepted dimensions, and reject or normalise anything that would create uncontrolled series growth.
The same principle shows up in external guidance for agent systems. The OWASP Agentic AI Top 10 highlights identity and privilege abuse, tool misuse, and related agent risks, which is relevant here because telemetry that cannot be aggregated cleanly also becomes harder to use for detection, attribution, and response. Clean labels are part of making agent behaviour observable at all.
Risk and Threat Considerations
High-cardinality labels create a visibility and cost risk even before they create a security problem. At scale, they can overwhelm metric backends, slow queries, inflate bills, and hide the few series that actually matter during an incident.
Failure mechanism: An agent emits unbounded label values, such as request-specific identifiers or raw text, which multiplies time series and destroys aggregation efficiency. Alerting and SLOs then fail because the signal is scattered across too many unique series.
Impact: Teams lose fast operational visibility, incident response slows down, and the telemetry pipeline may become too expensive or noisy to trust during real outages.
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 addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent telemetry can hinder detection when labels explode from agent actions and contexts. |
| Recommendation — Limit agent telemetry labels so behaviour remains attributable and aggregable. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and systems are monitored to detect cybersecurity events | Telemetry design directly affects monitoring quality and alert usability. |
| GV.RM-01 — Risk management strategy is established and communicated | High-cardinality telemetry creates operational risk that needs governance and standards. | |
| Recommendation — Design metrics to support continuous monitoring with stable, low-cardinality signals. Set telemetry standards that cap label cardinality and preserve monitoring value. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Metrics that become unbounded reduce the value of operational logging and monitoring. |
| Recommendation — Separate aggregate metrics from detailed event records and preserve usable audit signals. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | Agents should not leak dynamic error text or raw paths into telemetry labels. |
| Recommendation — Keep logging and telemetry fields bounded so error handling remains analyzable. | ||
Practitioner Guidance
What to verify: Review every label the agent can emit and confirm that each value comes from a controlled, finite set. If a label can take on unlimited values, move it out of metrics before it reaches production.
What good looks like: Metrics should be stable enough that the same series exists across many runs, with only a few bounded dimensions changing. If a dashboard is dominated by one-off series, you are measuring request detail, not operational health.
Common mistake: Teams often allow agents to mirror structured logs into metrics because it feels convenient. That shortcut usually creates the exact fragmentation and query pain that metrics were meant to avoid.
Practitioner takeaway: Keep metrics low-cardinality by design, and send rich per-request detail to logs or traces so agents remain observable without turning your metric store into a data dump.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org