You Can't Govern What You Can't See
Correlated Observability for AI: One Identity, Three Surfaces
What does it take to answer "what did agent X do yesterday?" in your environment?
For most platform teams running AI infrastructure today, it means pulling up an LLM gateway dashboard, an MCP proxy log, and an agent orchestration trace, then matching timestamps until the picture lines up.
What's missing is a common identity threading through all three so the chain doesn't have to be reconstructed by hand.
What correlated observability means
Every action an agent takes resolves to the same identity, no matter which surface it happens on. The LLM call, the MCP tool invocation, and the agent-to-agent session all carry the same verifiable identifier. Query that identifier and you get a single chain across all three surfaces, without a log-stitching layer in between.
An API key tells you "someone with key X made a request" - not which agent instance, which session, or which workgroup. When agents share keys (common in practice), the logs can't distinguish between them at all.
A cryptographic identity ties every action to a specific agent instance, signed by a key only that instance holds. The correlation isn't reconstructed after the fact - it's structural.
The four types of visibility enterprises actually need
When platform teams describe what they want from AI observability, it tends to break down into four categories:
Usage visibility. Who is using which MCP tools, which LLM models, request volumes per team. This is what most gateway dashboards already provide, and it's necessary but not sufficient. The gap is correlating tool usage with agent identity and session context - not just "this tool was called 500 times today" but "agent X in workgroup Y called this tool during session Z under contract W."
Cost visibility. Token consumption per identity, cost per team and project, budget utilization and enforcement. LLM gateways handle this well for model costs. But when an agent orchestrates a chain of LLM calls and tool invocations across a multi-agent session, the total cost of that interaction is spread across multiple systems. Correlating it requires a common identity.
Security visibility. Policy violations, unauthorized access attempts, data flow patterns, full audit trails. This is where the gap between "logging" and "visibility" is sharpest. Logging tells you a policy was violated. Visibility tells you which agent violated it, what it was trying to do, which session it was part of, what contract governed that session, and what other agents were involved.
Governance visibility. Guardrail activations, tool permission enforcement, agent contract negotiations, cross-boundary data sharing events. This is the category most AI platforms don't address at all, because it requires understanding the relationships between agents - not just individual agent behavior.
All four require the same thing: a common identity that threads through every interaction.
Why identity is the key
If your agents authenticate to LLM providers with one set of credentials, to MCP servers with another, and to each other with a third, you fundamentally cannot correlate across those surfaces without building a separate identity mapping layer. And that layer is fragile, approximate, and perpetually out of date.
If your agents carry a single cryptographic identity that authenticates them everywhere - to the network, to the LLM Gateway, to the MCP Gateway, Agent-to-agent - then correlation is automatic. It falls out of the architecture. You don't need a log aggregation pipeline to stitch together three identity systems. The identity is the common thread.
This is what the NetFoundry AI platform provides. The same Ziti identity that authenticates an agent to the network also controls which LLMs it can access through the LLM Gateway, which MCP tools it can use through the MCP Gateway, and which other agents it can interact with through Agora.
What this looks like in practice
Consider a concrete scenario. An agent in your analytics team kicks off a research task:
The agent sends a request through the LLM Gateway to Claude, asking it to analyze market trends. The LLM response suggests pulling recent data. The agent makes a tool call through the MCP Gateway to a financial data MCP server. The data comes back. The agent then opens a session on Agora with a specialized summarization agent in another workgroup, passing the analysis for formatting.
With correlated visibility, the platform team sees the entire chain as a single story: agent identity X, authenticated via certificate Y, made LLM request at timestamp T1, triggered tool call at T2, opened Agora session S1 under contract C1 at T3. Cost: $0.47 total across the chain. All policy checks passed. No guardrail violations.
Without correlated visibility, the platform team has: an LLM Gateway log entry for a Claude request from API key A, an MCP Gateway log entry for a data tool call from token B, and an Agora session record for identity C. They're probably the same agent, but the logs alone can't prove it.
The difference is whether the chain shows up in a query or has to be reconstructed by hand from three separate log searches.
The competitive gap
This isn't a criticism of other platforms. They're good at what they do. The gap is in the kind of visibility they produce.
Kong's AI Gateway provides strong observability at the gateway layer - reasoning spans, token tracking, per-agent cost attribution. With Kong AI Gateway 3.14 (April 2026), Kong now spans all three surfaces: LLM, MCP, and agent-to-agent via Kong Agent Gateway. But each surface operates with its own gateway-tier identity, so correlating "what did agent X do across all three?" still requires stitching across separate observability surfaces. Kong shows you each surface clearly; what's missing is a single identity threading through them so the correlated chain shows up automatically.
Portkey provides 40+ metrics for LLM usage with excellent cost attribution and tracing. But Portkey has neither agent-to-agent capabilities nor network-level visibility. If an agent makes a Portkey-proxied LLM call and then communicates with another agent, those events are invisible to each other.
Tailscale Aperture extends WireGuard-based identity into an AI gateway with centralized LLM access, identity-tied usage logs, and integrations with coding agents. It's strong at correlating LLM requests with user identity. But Aperture doesn't cover MCP tool calls or agent-to-agent interactions, so the correlated view stops at the LLM boundary.
The differentiator isn't whether competitors cover the same surfaces - Kong now does - it's whether the same cryptographic identity threads through every interaction, so the correlated view falls out of the architecture instead of requiring a stitching layer.
Visibility as the bridge between security and enablement
There's a practical reason platform teams care about this beyond security.
The number one thing that slows down AI adoption in enterprises is organizational confidence, not technical limitations. Leadership asks, "How are our teams using AI?" and the platform team can't give a precise answer. So the default response is caution: restrict access, slow down rollouts, add approval gates.
Correlated visibility inverts this dynamic. When the platform team can show leadership exactly how AI tools are being used - per-team costs, policy compliance rates, data flow patterns, guardrail effectiveness - they can justify expanding access rather than restricting it.
This is the same pattern we've seen with every infrastructure shift. VPNs restricted access because they couldn't provide granular visibility. Zero trust expanded access because it could show exactly who was connecting to what. AI infrastructure is on the same trajectory. The organizations that can see what's happening will move faster than the ones that can't.
Visibility is what makes security and enablement the same conversation.
Try it
The open source components are all Apache 2.0:
- Agora - governed agent network with workgroups, contracts, sessions, and envelope-level audit trails
- LLM Gateway - identity-based LLM access with cost controls and guardrails
- MCP Gateway - secure MCP tool access with structural permission enforcement
- OpenZiti - the zero-trust overlay network
For the full platform with commercial visibility dashboards, orchestration, and enterprise support, we at NetFoundry are working with a small group of design partners through the AI Accelerator program. If the fragmented-observability problem described here is real for your team, we'd like to hear about it.
