Because metrics measure activity, not legitimacy. Token counts, cost attribution, and failure rates are useful for internal control, but they do not tell another organisation whether the agent should be trusted, insured, or paid. Trust in open agent systems needs more than telemetry from one gateway.
Why usage metrics fall short of the trust question
Usage metrics are an internal telemetry layer, not a trust instrument. They can show volume, latency, spend, error rates, or how often an agent touched a tool, but they do not establish who the agent is, what authority it actually has, or whether a counterparty should accept its actions. In open agent ecosystems, that distinction matters because legitimacy is a governance and verification problem, not a usage chart.
That is why a platform can report “healthy” activity while still being unsafe to rely on externally. A high request count may simply mean the agent is busy, not that it is authorised, bounded, attributable, or operating under a trustworthy identity model. Trust depends on controls around delegation, provenance, and policy enforcement, not on operational convenience metrics alone.
The same gap appears in commercial relationships. If another organisation is deciding whether to let an agent trigger payments, access data, or act on its behalf, it needs evidence about authority, constraints, and accountability. Internal usage telemetry may help the operator manage performance, but it does not prove to a partner that the agent is safe to trust, insure, or remunerate.
What trust requires beyond telemetry
Trust in agentic systems usually depends on several separate questions: is the agent identifiable, is its authority explicit, can its actions be constrained per request, and can those actions be audited after the fact? Usage metrics touch only the last layer indirectly. They are useful for observability, but they do not answer whether the agent should have been allowed to act in the first place.
That is why policy-bound authorisation, delegated authority, and action-level accountability matter more than aggregate dashboard values. An agent can have excellent uptime and still be overprivileged, or it can have modest usage and still be operating with standing access that creates excessive blast radius. The control objective is not “more telemetry”, it is “verifiable and limited authority”.
This is also where open systems differ from closed ones. A single gateway’s logs may support local operations, but they rarely provide the cross-organisational evidence needed for trust decisions between independent parties. If the business question is “should we accept this agent’s request?”, the answer must rest on attestable identity, scoped permissions, and governance signals that travel with the agent, not just runtime counters inside one environment.
How to judge whether the trust gap is actually closed
The practical test is whether a third party can evaluate the agent without relying on your internal dashboard. If the only proof available is “it has low error rates” or “the gateway shows normal usage”, the trust problem is still open. A stronger posture exists when the organisation can demonstrate identity, delegated scope, approval path, and revocation path for the agent’s actions.
Open agent systems also need separation between observation and authority. Metrics are valuable for operations, capacity planning, and anomaly spotting, but they should not be mistaken for an entitlement model. In practice, the question is whether the organisation can revoke access, narrow action scope, and attribute a specific action to a specific principal when something goes wrong.
That makes the real control challenge one of evidence quality. Trust improves when telemetry is combined with policy, identity, and action history, so that a counterparty can verify what the agent is allowed to do and what actually happened. Without that combination, usage metrics can be useful, yet still insufficient for trust.
Risk and Threat Considerations
When organisations treat usage metrics as a proxy for trust, they can miss overprivilege, hidden delegation, and cross-boundary abuse. An agent may appear well-behaved in internal reporting while still being able to take actions that exceed the expectations of a partner, customer, or platform owner.
Failure mechanism: Metrics summarise activity after the fact, but they do not prove legitimate authority, so a system can look healthy while still permitting unauthorised or over-scoped agent actions.
Impact: That creates exposure to unsafe access decisions, misplaced reliance by third parties, and delayed detection of agent misuse, because the control failure is in the trust model rather than the telemetry.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Directly addresses agent authority and privilege, which usage metrics cannot prove. |
| ASI09 — Human-Agent Trust Exploitation | Trust misuse is central when parties over-rely on surface signals like telemetry. | |
| Recommendation — Enforce per-action authorization and limit agent privilege to the minimum delegated scope. Validate trust decisions with explicit authority and provenance checks, not activity counts. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | External trust depends on verifiable identity for non-organisational agents and counterparties. |
| AC-6 — Least Privilege | The answer hinges on limiting agent authority beyond what usage metrics can show. | |
| AU-2 — Event Logging | Telemetry is useful for auditing, but logging alone does not establish trust. | |
| Recommendation — Authenticate non-organisational actors before allowing agent actions or data access. Constrain each agent to the minimum permissions needed for its delegated task. Log agent actions with enough context to support attribution and review. | ||
Practitioner Guidance
What to verify: Ask whether the evidence set can support a trust decision without internal assumptions. For external use cases, verify that the agent’s identity, scope of authority, and revocation path are explicit enough that a counterparty can evaluate them independently of your usage dashboard.
Decision rule: If the question is “can we operate this safely?”, metrics may be sufficient for internal operations; if the question is “should someone else trust this agent?”, require authorisation and accountability evidence, not just operational telemetry.
What practitioners underestimate: High-quality metrics can create a false sense of control because they improve visibility without reducing delegated risk. The right standard is whether the agent’s actions are bounded, attributable, and externally defensible.
Practitioner takeaway: Use usage metrics to manage the agent, but use identity, policy, and accountability evidence to make trust decisions.