Measuring What Percentage of LLM Traffic Is Actually Governed

Define governed in measurable terms

Most coverage claims rest on policy documents, gateway inventories or sampled logs. Each shows that something exists or that some traffic was seen. None shows that policy was applied to a given interaction. NIST draws a similar line when it separates having policies in place from implementing them effectively. A document establishes the first. Only measurement of live traffic establishes the second.

A workable definition has three conditions. First, policy is evaluated in the execution path, before the request or response completes. Second, a decision is applied: allow, redact, block, rate limit or escalate for human approval. Third, the enforcement point itself writes an evidence record of that decision. An interaction that meets all three is governed. An interaction that meets none, or only the third through after-the-fact log collection, is not.

This gives three states that should stay separate in the metric: observed, logged and enforced. Observed traffic was seen by some tool. Logged traffic was recorded. Enforced traffic had policy applied with an outcome. Only the last counts as governed. Scope matters too. The unit here is the individual interaction or tool call. A coverage percentage at this level says nothing about whether a multi-step workflow was governed end to end, and it should not be presented as if it did.

Build the numerator and denominator

Start by fixing the unit of count. One model request and its response is one interaction. One invocation of a tool by a model or agent is one tool call. Count each separately. Tool calls belong in the denominator because tool calls and API requests are recognized exfiltration paths for agents, so leaving them out would flatter the result.

The numerator is the number of interactions and tool calls that were evaluated by enforced policy in a stated period, each backed by an evidence record. The denominator is every LLM-related interaction and tool call you can find across all paths, whether sanctioned or not. Coverage is numerator divided by denominator, ideally broken down by path, such as application, coding assistant, browser or agent tool call, so the gaps are visible rather than averaged away.

Treat this as a defined metric, not an ad hoc count. NIST expects measurement methods to be objective, repeatable and documented, and expects measures of uncertainty. Write down the unit, the period, the discovery sources behind the denominator and the rule for what enters the numerator before you take the first reading. The EU AI Act text takes the same approach for high-risk systems, requiring testing against metrics defined in advance. Whether that obligation applies to a given deployment is a separate legal question, but the discipline of fixing the metric first carries over.

Establish the denominator from several discovery sources

The denominator is the hard part, because it depends on finding traffic you did not plan for. No single source is complete, so combine several and deduplicate. Each has blind spots that the others should cover.

• Network and egress telemetry: Shows which AI destinations are being reached and in what volume. Visibility is weaker for traffic that leaves the monitored network, such as unmanaged devices, and it usually cannot attribute a call to a specific tool or actor.
• API key and SaaS inventories: Show what was provisioned or approved. They describe what could be used rather than what is used, and they miss keys and accounts created outside procurement.
• Browser and endpoint signals: Detect use of AI sites and locally installed applications. Coverage depends on how widely the endpoint or browser component is deployed.
• MCP server and coding assistant discovery: Finds tool servers and assistants configured on developer machines and in repositories. Configuration shows connection, not volume, so pair it with traffic data.
• Enforcement-point counts: The reconciliation source. Anything the other sources see that does not appear in enforcement counts is a measured gap.

Recognize the bypass paths that overstate coverage

Coverage is overstated when the denominator is incomplete or when traffic is counted as governed without passing through enforcement. Test each path below and record whether it is detected, closed or still open. An open path is not a failure of the metric. It is the metric working.

• Direct provider API calls: Applications or scripts that call a model provider with their own credentials. Detect through egress destinations and key inventories. Close by restricting egress to the enforcement point.
• Unsanctioned AI sites: Browser use of public AI services. Detect through browser and endpoint signals. Close by routing or blocking at the enforcement point.
• Embedded SDKs: Libraries inside applications that call models without an obvious integration point. Detect through dependency review and egress analysis.
• Agent tool calls and MCP connections: Tool invocations that do not pass through the same path as the model request. Detect through tool and server discovery. Close by placing enforcement on the tool call itself.
• Local model use: Models running on endpoints produce no external traffic. Detect through endpoint signals and decide explicitly whether they are in scope.

Report the figure with its limits

Present the percentage with the discovery sources that produced the denominator, the period covered, the paths known to be open and the uncertainty that remains. NIST notes there is no consensus yet on verifiable measurement methods for AI risk, so disclosing your method and its limits is more defensible than presenting a single clean number. Track the figure over time and by path. A rising overall percentage that hides an unmonitored coding assistant population is not progress.

This is where enforcement architecture determines whether the metric is credible. Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with outcomes of allow, redact, block, rate limit or escalate for human approval. The same enforcement produces audit-ready evidence, mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST, so the numerator is a count of enforcement records rather than an estimate. Scope is individual interactions and tool calls. The denominator still depends on discovery, and it should be reconciled against enforcement counts on a regular schedule.