TL;DR: Coding agents can now generate complete code changes, but observability still depends on explicit human-authored standards for spans, metrics, logs, and severity rules, according to Sawmills. The practical shift is from adding telemetry after code works to defining agent-readable instrumentation contracts before implementation.
At a glance
What this is: Sawmills argues that coding agents expose a gap between basic auto-instrumentation and the human-defined observability standards needed to explain software behavior in production.
Why it matters: For IAM and security teams, the lesson is that agent-built systems need enforceable operational contracts, because telemetry quality now affects incident response, accountability, and trust in AI-assisted delivery.
Context
Coding agents change instrumentation risk because they can now write multi-file changes, not just suggestions. That shifts the observability problem from manual developer judgment to governance over the telemetry contract, especially where business events, severity, and traceability must remain consistent across services.
Auto-instrumentation can capture transport-level activity, but it cannot infer the operational meaning of a customer journey or a failure taxonomy. In AI-assisted delivery, the question is no longer whether code runs, but whether the system can explain itself when production fails.
Key questions
Q: What breaks when coding agents do not have governed observability?
A: Verification breaks first, then debugging, then trust in the agent’s output. If telemetry is missing, noisy, or inaccessible, the agent cannot compare its changes with runtime evidence and humans cannot audit the decision path. That quickly turns automation into review overhead instead of control.
Q: Why do high-cardinality labels create problems in agent-generated telemetry?
A: 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.
Q: What do security and platform teams get wrong about log severity in AI-assisted development?
A: They let severity emerge from individual code paths instead of a shared operational taxonomy. That leads to harmless business outcomes being logged as errors, real failures being buried in noise, and alert fatigue across on-call teams. Severity has to mean the same thing everywhere if telemetry is going to support incident triage.
Q: How should teams govern observability for coding agents and human developers together?
A: Use the same contract for both. Define approved instrumentation libraries, required spans, allowed metric labels, severity rules, forbidden data types, and correlation fields in repository-level guidance and CI checks. Then require agents and humans to produce telemetry that supports dashboards, runbooks, and incident review without relying on local judgment.
Technical breakdown
Why auto-instrumentation stops short of operational meaning
Auto-instrumentation, including eBPF-based approaches, can observe network calls, protocol activity, and basic latency without code changes. What it cannot reliably infer is the business context that gives those signals meaning, such as whether a failed payment was a decline, a timeout, or a fraud rejection. That distinction matters because observability is not only about seeing traffic. It is about producing actionable semantics through spans, metrics, logs, and attributes that match how the service actually fails. Coding agents can generate code that looks instrumented but still lacks those human-defined semantics.
Practical implication: Define the allowed telemetry semantics before agents generate code, not after incident gaps appear.
How cardinality and severity rules shape usable telemetry
Metrics become noisy when agents copy high-cardinality values such as user IDs, order IDs, dynamic paths, or exception messages into labels. Logs become noisy when severity is inferred from surrounding code instead of a shared policy. Both problems reduce signal quality and can create false confidence during incidents. A useful observability contract separates bounded metric dimensions from request-level trace and log detail, and it gives each severity level a stable operational meaning. That is what keeps telemetry searchable, aggregatable, and trustworthy under pressure.
Practical implication: Restrict metric labels and standardise severity so agents do not turn observability into cost and alert fatigue.
Why traces, logs, and dashboards need a shared contract
The most common observability failure is not absence of signals but fragmentation between them. A useful alert path should let an engineer move from a dashboard to a metric dimension, then to a trace exemplar, then to a span and its log event, and finally to the runbook. If an agent adds telemetry in only one layer, the chain breaks. The result is a system that emits data but still cannot explain itself. In practice, that means telemetry design must include naming conventions, required attributes, correlation IDs, and incident-ready runbooks as part of the same standard.
Practical implication: Treat correlation fields, naming conventions, and runbooks as one control surface instead of separate afterthoughts.
Threat narrative
Attacker objective: The practical objective is not data theft but degraded observability that slows detection, triage, and recovery.
- Entry occurs when a coding agent is allowed to generate application changes without a repository-level observability standard to constrain instrumentation choices.
- Credentialed access to code and deployment tools lets the agent propagate its own telemetry assumptions across spans, logs, and metrics.
- Escalation happens when high-cardinality labels, misleading severity, or missing correlation fields make the service harder to diagnose during an incident.
- Impact is operational blindness: the service may still function, but teams lose the ability to explain failures quickly and consistently.
Breaches seen in the wild
- PocketOS database deletion incident: An AI coding agent found an over-privileged Railway API token in the codebase and deleted PocketOS production data and backups in nine seconds.
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Observability contracts are now a governance control, not a developer preference. Coding agents reduce the amount of human attention spent on implementation details, which means the telemetry model has to be explicit before code is written. If spans, metrics, and log rules are left to local judgment, each agent will reproduce repository inconsistency at scale. The practitioner conclusion is simple: observability standards now belong in the control plane of software delivery.
High-cardinality telemetry is an agentic risk amplifier: agents will often make metrics look more informative by adding more labels, but production observability depends on bounded dimensions. That is especially relevant where the business wants traceability without turning metrics into an unusable data swamp. For teams running AI-assisted development, the issue is not just cost. It is whether the telemetry surface remains queryable during an incident.
Severity drift is a control failure, not a style issue: when each service or agent invents its own meaning for error and warn, responders lose the ability to distinguish expected business outcomes from actual failures. That weakens operational triage and obscures SLO impact. The named concept here is telemetry semantics drift, and it describes what happens when message meaning stops being stable across services. The practitioner conclusion is to standardise severity and failure taxonomy as a governed rule set.
Agent-written code still needs human-authored truth conditions. Coding agents can infer nearby patterns, but they cannot reliably know when an order is truly created, a payment is retryable, or a failure should be represented as a business event rather than an error. That makes observability design a documentation and governance task, not a prompt-engineering trick. The practitioner conclusion is to encode operational truth in contracts the agent can read and follow.
Identity and access teams should care because AI coding agents are becoming trusted producers inside delivery pipelines. Once an agent can modify code, run commands, and prepare pull requests, its output becomes part of the system of record for operational trust. That means telemetry policies, review gates, and repository standards need the same attention as secrets and permissions. The practitioner conclusion is to govern agent output as production evidence, not just source code.
From our research library:
- Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
- Read next: AI Coding Agents Security Guide
What this signals
Telemetry semantics drift: When agent-written code inherits inconsistent logging and metrics conventions, observability becomes a governance problem rather than a tooling problem. Teams should treat naming, severity, and correlation as controlled standards that must be validated before merge, not cleaned up after the first incident.
AI-assisted delivery changes the meaning of “done” because a feature that works but cannot be explained is still an operational liability. The practical shift is toward repository-level observability contracts that make instrumentation auditable, repeatable, and safe across every service change.
For practitioners
- Define an observability contract before agentic coding begins Document approved logger, tracing library, metric naming, span naming, required fields, forbidden labels, severity meanings, and failure taxonomy in a machine-readable repository file.
- Constrain metric cardinality and log payloads Ban labels such as user_id, order_id, raw path, exception_message, and request body from metrics, and reserve request-level detail for traces or structured logs.
- Require telemetry tests in CI Test success, expected business failure, and unexpected system failure cases so agent-generated code cannot merge without the required spans, metrics, and logs.
- Add correlation requirements to runbooks Require trace IDs, stable event names, dashboard links, and runbook references so responders can move from alert to trace to remediation without guessing.
- Make agents plan instrumentation before implementation Force the agent to list spans, metrics, log events, cardinality risks, privacy risks, dashboards, and runbooks before code is written.
Key takeaways
- Coding agents increase the volume of code teams can ship, but they also increase the risk that telemetry will be inconsistent, misleading, or incomplete.
- The central failure mode is not a lack of observability tools, but a lack of explicit standards for spans, metrics, logs, severity, and correlation.
- Teams that define observability as a contract before implementation are better positioned to keep AI-assisted software explainable during incidents.
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 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent-written code can propagate unsafe telemetry and operational assumptions through trusted delivery workflows. |
| ASI08 — Cascading Failures | Poor instrumentation in one service can break incident diagnosis across the whole delivery chain. | |
| Recommendation — Govern agent output with bounded permissions and review so it cannot introduce uncontrolled telemetry behavior. Design telemetry standards to prevent local instrumentation mistakes from cascading into platform-wide observability gaps. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | The article stresses preventing sensitive operational data from leaking into logs and metrics. |
| DE.CM-01 — Networks and network services are monitored | The post discusses structured monitoring and correlation across traces, logs, and dashboards. | |
| Recommendation — Apply data protection rules to telemetry content so logs and metrics do not expose secrets or personal data. Use monitored service telemetry to confirm that logs, metrics, and traces cover the critical user journey. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | The core issue is whether operational records remain useful for incident review and analysis. |
| Recommendation — Review telemetry quality as audit evidence and enforce analysis-ready logging across services. | ||
Key terms
- Observability contract: A documented set of rules that defines how a service should emit logs, metrics, and traces. It specifies approved libraries, field names, severity meanings, forbidden data, and the signals required to support debugging, incident response, and operational accountability.
- Telemetry Drift: Telemetry drift is the gradual divergence of data formats, ingestion rules, or routing behaviour across sources and tenants. It creates hidden operational risk because the pipeline still runs, but the assumptions behind parsing, enrichment, and compliance are no longer consistent.
- Cardinality: The number of unique attribute combinations in telemetry data. High cardinality increases the number of metric series and can inflate cost, overwhelm backends, and make analysis noisy unless attributes are normalised or removed before export.
- Business-Outcome Logging: Logging that records stable operational events instead of raw developer detail. It focuses on what changed, whether the action succeeded, and how the system should be interpreted, rather than duplicating traces or exposing noisy request data.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and the operational controls that matter when software delivery becomes more automated. It helps security and identity practitioners build the governance discipline needed to support AI-assisted systems at scale.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org