They should capture tool calls at the proxy-to-upstream hop, not just tunnel lifecycle events. That hop is where the actual request, arguments, and response are visible, so it is the only place that can tell you what the agent really did. Administrative logs alone do not reconstruct usage.
What to inspect in MCP audit data when the proxy terminates the client side
If the proxy forwards plaintext upstream, the audit boundary moves to the proxy-to-upstream hop. That is where the actual tool call, arguments, and returned content exist in a form you can review, so it is the only place that can prove what the agent really asked for and received.
That means the audit goal is not just to confirm that a session existed, but to preserve the request context that explains the action. Tunnel metadata can tell you that traffic passed; it cannot tell you whether the agent listed files, queried a secret-bearing tool, or invoked a destructive operation.
When teams design logging around this pattern, they should treat the upstream-facing hop as the source of truth for usage review, incident reconstruction, and policy checks. If the proxy only records connection lifecycle events, the audit trail will be too thin to answer basic questions about intent, scope, and response content.
How to make proxy-side logging actually useful
Capture the full tool invocation record at the proxy boundary: tool name, arguments, selected resource or target, response payload, timestamps, and any actor or session identifiers needed to correlate the event. The value comes from being able to reconstruct the exact interaction, not from having a larger volume of generic logs.
Normalization matters as much as collection. Keep enough structure to search by tool, command, account, and downstream resource, because plain text logs become far less useful if they cannot be filtered or correlated during triage. For MCP-heavy environments, that correlation is often the difference between knowing “something happened” and knowing which action was executed.
Where teams also need a broader operating model for MCP, the MCP Security Guide is the most direct internal reference for the authorization model, token handling, and gateway patterns around this traffic.
Why tunnel-only logs miss the real control point
Audit records taken before the proxy decrypts or after it re-encrypts the session can miss the security event that matters most: the actual request content. In practice, that creates a blind spot for misuse, overbroad tool access, and hidden data exposure inside otherwise legitimate sessions.
It also creates a false sense of completeness. An operator may see a normal connection lifecycle, while the proxy-to-upstream hop contains the only evidence that the agent sent a sensitive prompt, invoked the wrong tool, or received output that should have been constrained.
For teams operating agentic workflows, the agentic AI applications guide helps frame why tool-use logging, not just transport logging, is central to understanding what autonomous systems actually did.
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 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | MCP tool calls can be abused through the proxy boundary and must be auditable. |
| ASI03 — Identity & Privilege Abuse | Proxy-visible requests reveal whether an agent used its authority beyond intended scope. | |
| ASI09 — Human-Agent Trust Exploitation | Audit records help detect cases where a human or agent trusted an unsafe tool interaction. | |
| Recommendation — Log upstream tool invocations to detect and review misuse of agent tooling. Correlate tool calls to the invoking identity and flag privilege overreach. Capture request and response content to review trust-sensitive agent interactions. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | The subject is about which events must be logged to reconstruct MCP activity. |
| AU-12 — Audit Record Generation | Useful audit requires generating records at the hop where the request is visible. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Teams need reviewable records that reconstruct tool use, not just connectivity. | |
| Recommendation — Define proxy-to-upstream events as auditable events for MCP traffic. Generate structured audit records at the proxy boundary where plaintext is observable. Review proxy logs for actual tool actions, arguments, and returned content. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | This topic is about capturing the right log content for investigation and oversight. |
| Recommendation — Centralise and retain proxy logs that show actual MCP tool activity. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | MCP traffic often rides authenticated calls, so audit data must bind requests to the right actor. |
| API8 — Security Misconfiguration | A plaintext forwarding path can leave important request details unlogged or misrouted. | |
| Recommendation — Validate that each logged tool call maps to the authenticated caller and session. Check that proxy logging is configured to preserve upstream request visibility. | ||
Practitioner Guidance
What to verify: Confirm that the proxy log stream captures the upstream request and response, not only session start and stop events. If you cannot reconstruct the tool call from logs alone, you do not yet have an audit trail suitable for investigation or review.
What to prioritise: Preserve enough context to tie each call to an actor, a session, and a downstream tool action. That makes later review practical, especially when the same proxy fronts multiple agents or multiple tools with similar traffic patterns.
Common mistake: Treating “we logged the tunnel” as equivalent to “we audited the action.” Those are different controls, and only the latter can support meaningful accountability when tool output or arguments are disputed.
Practitioner takeaway: If the proxy is the only place where plaintext exists, that hop is the audit source of truth, so logging must be designed to reconstruct tool use rather than merely prove connectivity.