Kong A2A and MCP metrics expose the governance gap in AI tool adoption

At a glance

What this is: This is Kong’s product analysis of A2A and MCP metrics, arguing that enterprise AI governance fails when teams can see uptime but not actual tool adoption, usage patterns, or cost drivers.

Why it matters: It matters because IAM, platform, and governance teams need telemetry that shows how agents and tools are being used before they can decide what to allow, restrict, or scale.

Context

AI tool adoption is no longer just a deployment question. Once agents begin calling tools through MCP and coordinating through A2A, the governance problem shifts from whether the system is available to whether anyone can see what it is actually doing.

Kong’s article focuses on that visibility gap for AI Gateway users: platform teams may have infrastructure telemetry, but without usage, latency, and consumption data they cannot govern adoption, cost, or access with confidence.

The article is essentially about AI governance and operational observability for enterprise agent deployments, not about the mechanics of model inference itself.

Key questions

Q: How can organisations tell whether AI governance is actually working?

A: Organisations can tell AI governance is working when they can inventory every agent, explain its purpose, show who owns it, and prove that permissions are tightly scoped. If those four things are missing, the programme has policy language but not operational control. Auditors will notice the gap quickly.

Q: Why do uptime and latency metrics fail to govern agentic AI programmes?

A: Because they show service health, not control effectiveness. An AI platform can be fast and available while agents still use the wrong tools, bypass intended routing, or drive unexpected costs. Governance needs telemetry that links requests to actors, tasks, scopes, and consumption so the organisation can see what the system is doing, not just whether it is responding.

Q: What breaks when AI tool access is not tied to usage and scope telemetry?

A: Teams lose the ability to tell whether low adoption is caused by poor training, broken integration, or overly broad or narrow access. That means access reviews, support decisions, and cost planning become guesswork, and policy often changes only after the programme has already drifted into shadow usage or unnecessary friction.

Q: How should teams decide who owns AI gateway governance as adoption scales?

A: Ownership usually shifts toward platform and infrastructure teams because they can see the traffic and enforce the controls closest to execution. That only works if security, IAM, and AI governance requirements are built into the operating model, so technical ownership does not become a blind spot for access, risk, or accountability.

How it works in practice

Why uptime metrics do not govern AI tool adoption

Uptime and latency are infrastructure signals, not governance signals. A gateway can tell you that requests are flowing, but it cannot by itself show whether agents are using the right tools, whether tool access is broadly adopted, or whether usage patterns are concentrated in a way that creates cost and control risk. That distinction matters because AI programmes fail when operational telemetry is mistaken for governance evidence. For A2A and MCP, the relevant unit is not just the request path, but the relationship between the agent, the consumer, the task, and the tool invocation that results.

Practical implication: measure AI adoption with usage and consumption telemetry, not only service availability.

A2A and MCP analytics as governance telemetry

A2A and MCP analytics extend observability from model traffic to the interaction layer where enterprise AI actually creates value and risk. Request counts, response latency, upstream latency, status codes, task IDs, context IDs, consumers, and agents together let teams answer different governance questions: what is being used, by whom, how often, and where the bottlenecks or blocked patterns appear. That is materially different from conventional API monitoring because the objective is not only service health but controlled adoption across many AI actors and tool chains.

Practical implication: build policy review and reporting around actor, task, and tool-level telemetry.

Why scope-based filtering matters for agentic control

When AI systems can reach multiple tools, governance has to constrain not just traffic volume but the scope of what each actor can invoke. Scope-based tool filtering, token exchange, and native A2A traffic management are control patterns for narrowing what an agent can do at runtime and for tracing that activity through the gateway. In practice, this is the difference between seeing AI as a generic workload and governing it as a set of distinct identities and paths. Without those controls, visibility remains descriptive rather than authoritative.

Practical implication: align tool access controls with the specific agent, consumer, and scope that generated each request.

NHI Mgmt Group analysis

AI adoption now has a governance telemetry problem, not just an observability problem. Uptime, latency, and request health do not tell security or platform teams whether agents are actually using approved tools in approved ways. Once adoption reaches enterprise scale, governance depends on usage evidence, blocked-request patterns, and consumption trends, not infrastructure health alone. The practitioner conclusion is simple: without actor-level telemetry, policy becomes retrospective.

A2A and MCP traffic create a new control plane for enterprise AI identity and access. The important shift is from monitoring models to monitoring interactions among agents, consumers, task IDs, and tools. That makes the gateway part of the governance architecture rather than a passive transport layer. For practitioners, this strengthens the case for treating AI tool access as a governed entitlement surface, not as an incidental API pattern.

Adoption friction is a lifecycle signal, not just a usage metric. Kong’s framing makes clear that low usage can reflect poor enablement, broken integrations, or mis-scoped access, and governance teams need to distinguish those causes before changing policy. That same pattern applies across human IAM, NHI governance, and agentic AI: visibility only becomes meaningful when it can support lifecycle decisions about access, support, or withdrawal.

Scope-based tool filtering is the right named concept for this control gap. The article shows that the missing discipline is not more raw telemetry, but telemetry tied to what an agent is allowed to reach and why. That is the practical governance boundary for AI tool adoption at scale. The implication for practitioners is to move from generic monitoring toward enforceable, scope-aware access governance.

The AI governance centre of gravity is moving toward platform teams. Kong’s own survey statistic shows decision-making shifting away from the executive suite and toward infrastructure owners, which is where the operational evidence lives. That creates both opportunity and risk: platform teams can enforce controls closer to the traffic, but only if security and governance requirements are built into the telemetry model. The practitioner conclusion is that AI governance will increasingly be won or lost in the platform layer.

From our research library:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Authorisation Guide

What this signals

AI tool adoption becomes governable only when telemetry captures who is using what, not just whether the service is up. Platform teams need actor-level visibility into A2A and MCP activity before access decisions can be defended, and that requirement is now part of the governance baseline for enterprise AI.

Scope-based tool filtering is the operational boundary that turns observability into control. When every agent invocation can be tied to a consumer, task, and tool scope, governance teams can distinguish legitimate adoption from overreach, and they can make access review decisions with evidence instead of instinct.

52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey. That shift makes telemetry quality a governance issue, not just an engineering one.

For practitioners

• Instrument AI adoption telemetry Track request counts, latency, task IDs, consumer IDs, and tool-level usage so policy decisions reflect real behaviour rather than assumed adoption.
• Separate availability from governance reporting Report uptime and latency as service health, but use blocked requests, tool consumption, and adoption trends for security and governance decisions.
• Apply scope-based tool filtering Limit each agent or consumer to the smallest tool scope that matches its role, and review those scopes against actual invocation patterns.
• Use adoption friction as a control signal When usage is low, investigate whether the cause is training, integration failure, or overly restrictive access before changing policy or expanding entitlements.
• Treat AI gateway data as governance evidence Feed gateway metrics into access reviews, platform reporting, and AI risk discussions so control owners can justify expansion, restriction, or remediation.

Key takeaways

• AI tool adoption cannot be governed well if teams only measure infrastructure health instead of actual usage and access patterns.
• The central evidence gap is between AI traffic visibility and AI governance visibility, which is where policy decisions often fail.
• Practitioners need scope-aware telemetry, actor-level reporting, and gateway data that can support access, adoption, and cost decisions.

Key terms

• A2A Telemetry: A2A telemetry is the observability data generated by agent-to-agent communication, including request counts, latency, status, and routing context. In practice, it lets governance teams see how autonomous or semi-autonomous agents interact and whether those interactions stay within approved operational scope.
• MCP Metrics: MCP Metrics are measurements used to evaluate how Model Context Protocol integrations behave in production. They track tool usage, request volume, latency, failures, authorization outcomes, and context quality. In practice, these metrics help security and platform teams understand agent activity, detect misuse, and govern access to tools and data.
• Scope-based Tool Filtering: Scope-based tool filtering limits which tools an AI system or agent can call based on the authority it has been granted. It is a runtime control, not a static label, and it becomes essential when agent behaviour can change from one task to the next.
• AI Governance Telemetry: Operational signals that show how AI policies are being applied in practice, including blocked prompts, masked outputs, and review events. These signals help governance teams prove whether controls are working and identify drift between policy intent and real-world usage.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.