Join our Newsletter — 33% off our NHI Course

How should teams govern telemetry when coding agents are creating instrumentation?

Use policy checks for new tags, metric dimensions, and log fields before code is merged or deployed. Agents can generate plausible defaults at machine speed, so the control must shift from human review alone to automated enforcement at the pipeline boundary.

Why This Matters for Security Teams

telemetry is often treated as harmless operational exhaust, but when coding agents create instrumentation, they are also making decisions about what the organisation can observe, correlate, and trust. New tags, metric dimensions, and log fields can expose sensitive data, distort alert logic, or create high-cardinality noise that weakens detection. The governance problem is not only data quality; it is also security control integrity and auditability.

This is why guidance from the NIST AI Risk Management Framework matters here. The issue sits at the intersection of AI output governance and operational security: an agent can draft instrumentation that looks correct, but still introduce privacy leakage, unapproved collection, or blind spots in incident response. Agentic workflows amplify this because changes can be generated faster than a human reviewer can inspect them line by line. In practice, many security teams encounter telemetry abuse only after a dashboard has already filled with unusable fields or a sensitive attribute has already been shipped into logs.

How It Works in Practice

Effective governance starts with treating instrumentation as controlled code, not as a low-risk byproduct. Teams should define an approved schema for logs, metrics, and traces, then require automated checks at pull request and build time to compare agent-generated instrumentation against that schema. That means blocking new fields unless they are explicitly approved, validating allowed tag values, and enforcing naming conventions that preserve searchability and routing.

Security and platform teams should also decide which telemetry elements are prohibited by default. For example, free-form user input, secrets, tokens, full account identifiers, and raw payloads should not be emitted unless there is a documented reason and a retention control. The OWASP Top 10 for Agentic Applications 2026 is useful as a reference point because agent outputs need the same kind of guardrails as other autonomous actions: validation, approval boundaries, and traceability.

  • Gate instrumentation through policy-as-code in CI/CD.
  • Use allowlists for approved event names, dimensions, and labels.
  • Reject telemetry that introduces high-cardinality or unbounded values.
  • Scan generated code for secrets, personal data, and sensitive identifiers.
  • Require ownership for each new signal so alerts and dashboards have a clear custodian.

Operationally, this should also include sampling and retention controls, because telemetry governance is not complete if data collection is technically safe but operationally excessive. Organisations that use agents for observability work should align security review with the same pipeline that approves application code, not a separate after-the-fact dashboard review. These controls tend to break down when legacy services emit unstructured logs and teams have no central schema registry, because there is no reliable baseline to validate against.

Common Variations and Edge Cases

Tighter telemetry controls often increase developer friction and can slow incident investigation, requiring organisations to balance observability depth against privacy, cost, and operational speed. That tradeoff becomes sharper in distributed systems, where some teams want broader capture for troubleshooting while others need strict minimisation for regulatory or contractual reasons.

Current guidance suggests there is no universal standard for every telemetry decision, especially when agents generate instrumentation dynamically. In regulated environments, the answer is usually to prefer explicit approval for new fields and conservative defaults for collection. In fast-moving engineering teams, a lighter process may be acceptable if the policy engine is strong enough to block sensitive output automatically.

The exception cases are usually the hardest ones: temporary debug logging, feature-flagged telemetry, and incident-response overrides. Those should be time-bound, documented, and reversible. The NIST Cybersecurity Framework 2.0 is helpful for aligning governance with asset oversight and continuous monitoring, while the MITRE ATLAS adversarial AI threat matrix is useful when evaluating how malformed or manipulated instrumentation could affect detection pipelines. Best practice is evolving, but the core principle is stable: if an agent can invent telemetry, the organisation must be able to approve, constrain, and later explain it.

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, MITRE ATLAS and CSA MAESTRO 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
NIST AI RMF AI RMF governs trustworthy AI outputs, including agent-generated telemetry.
OWASP Agentic AI Top 10 Agentic AI guidance addresses autonomous actions that create or modify telemetry.
MITRE ATLAS ATLAS helps model adversarial abuse of AI outputs and telemetry pipelines.
NIST CSF 2.0 PR.DS Data security controls apply to sensitive fields emitted by generated instrumentation.
CSA MAESTRO MAESTRO supports threat modeling for agentic workflows that generate observability code.

Use ATLAS to assess how manipulated or malformed telemetry could distort detection and response.