Before, if they want reusable governance. Scaling first creates a proliferation of framework-specific field shapes, which makes every evaluator, dashboard, and alert more expensive to maintain. Standardisation does not eliminate churn, but it turns churn into a managed migration rather than a series of silent control failures.
Why telemetry has to come first if you want governance to scale
Telemetry is not just an observability detail, it is the control surface for how AI agents are evaluated, monitored, and constrained. If teams scale first and standardise later, they usually inherit incompatible event names, missing context fields, and uneven action traces across tools and models. That leaves governance teams comparing unlike records, which slows review and weakens enforcement.
Standardising before scale gives you a common language for agent identity, tool calls, approvals, failures, and outcome tracking. That is what makes policy portable across frameworks and makes dashboards, alerts, and audits reusable instead of bespoke per agent.
It also changes the economics of change. When the schema is stable first, you can migrate individual agents without redesigning the whole control stack each time a new orchestration layer, model provider, or toolchain is added.
What breaks when you scale agents on top of inconsistent telemetry
The main failure mode is not that teams lack data, it is that they lack comparable data. One agent may log a user-facing action, another logs only a tool invocation, and a third emits no durable trace at all. In practice that means evaluators cannot reconstruct intent, dashboards cannot trend behaviour, and alerts cannot distinguish a benign retry from a policy breach.
In larger agent fleets, that inconsistency turns into governance drift. The more framework-specific the field shapes become, the more every downstream consumer has to learn special cases. A control can still exist on paper, but if the telemetry required to prove it is fragmented, the control becomes hard to operate and harder to test.
Standardisation before scale also reduces hidden dependency risk. If your logging, tracing, and evaluation pipeline all assume different schemas, then onboarding a new agent or tool becomes a coordination exercise across several teams instead of a repeatable release pattern.
How to standardise without freezing the platform
The practical goal is not perfect permanence, it is a minimum shared schema that survives growth. Start by standardising the fields needed to answer the questions operators actually ask: who or what acted, what tool or capability was used, what policy decision was made, what input triggered the action, and what outcome followed. Once those fields are stable, teams can add product-specific metadata without breaking the common layer.
That is the difference between controlled evolution and telemetry sprawl. Standardisation should define the contract for core events, not every optional attribute. If you make the schema too rigid too early, teams will bypass it; if you make it too loose, you lose the comparability that scaling depends on.
For agent-heavy environments, the same logic applies to access decisions and audit trails. The telemetry model should preserve enough structure to support least-privilege authorisation for AI agents, because a policy that cannot be traced per action is difficult to defend operationally. It should also support review of agent behaviour using agent observability, audit, and incident response practices so that investigations do not depend on ad hoc logs from each platform.
Risk and Threat Considerations
When telemetry is standardised too late, organisations create blind spots that look like normal variation until an incident forces reconstruction. The risk is not only operational inefficiency, it is that inconsistent traces can hide overreach, misrouted actions, or failed policy enforcement across a growing agent estate.
Failure mechanism: divergent event schemas, missing correlation fields, and tool-specific logs prevent reliable comparison, which weakens monitoring, auditability, and control validation as the number of agents grows.
Impact: teams spend more time maintaining one-off parsers and manual review paths, while the chance of silent control failure rises because no single view can prove what each agent did or whether policy was applied consistently.
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 SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Telemetry must reveal per-action privilege use and policy decisions for agents. |
| Recommendation — Log and review each agent action against policy to detect privilege abuse early. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Standard telemetry depends on defined events for audit and accountability. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Comparable telemetry enables review, analysis, and alerting across agents. | |
| AU-12 — Audit Record Generation | Shared telemetry starts with consistent generation of the records you need. | |
| Recommendation — Define and capture the audit events needed for consistent monitoring and review. Review audit records centrally to spot inconsistent agent behaviour and policy drift. Generate audit records in a common format so downstream controls can consume them. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitor for Anomalies and Events | Standard telemetry underpins anomaly monitoring across a growing agent fleet. |
| Recommendation — Standardise events so anomaly monitoring works across all agents and tools. | ||
Practitioner Guidance
What to prioritise: define the smallest telemetry contract that supports governance before you approve broad agent rollout. The first version should be boring, stable, and usable across evaluators, not optimised for one product team.
What to verify: confirm that every agent event can be correlated end to end, from trigger to tool call to outcome, and that the same fields exist across environments. If the field map changes by agent type, you do not yet have a scalable control plane.
Common mistake: teams often wait for “real usage” before standardising, then discover that usage has already multiplied the number of schemas they must support. At that point the migration cost is higher and governance becomes reactive instead of designed.
Practitioner takeaway: scale should happen on top of a common telemetry contract, because governance becomes reusable only after the organisation can compare agent behaviour consistently across tools, models, and teams.
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