MCP servers create visibility gaps because tool invocation happens inside AI-mediated sessions that span multiple clients and often lack a clean audit trail. IAM teams may know the server exists, but not which tool was called, from which client, or whether the call matched the approved access scope. That makes runtime evidence essential for governance.
Why This Matters for Security Teams
MCP changes the visibility problem from “who has access?” to “what did the agent do inside a mediated session?” That matters because the server may be approved, yet the actual tool invocation can happen across multiple clients, chained prompts, and transient sessions that never map cleanly to a human-style login trail. Current guidance from the OWASP Agentic AI Top 10 and NHIMG’s Ultimate Guide to Non-Human Identities — Key Challenges and Risks both point to the same issue: runtime evidence is now part of identity governance, not an optional afterthought.
This is not just an audit problem. When IAM teams can see the server but not the tool, client, scope, or execution context, they lose the ability to answer basic questions about least privilege, approved use, and blast radius. That gap becomes more severe when secrets are embedded in configuration, because access can be invisible even when the endpoint is known. NHIMG’s AI Agents: The New Attack Surface report shows only 52% of companies can track and audit the data their AI agents access, leaving the rest with a compliance blind spot. In practice, many security teams discover MCP misuse only after a tool chain has already touched sensitive data, rather than through intentional visibility design.
How It Works in Practice
mcp server create gaps because the identity boundary is often too coarse for the activity being performed. A user or agent may authenticate to a client, the client may invoke an MCP server, and the server may then call one or more tools without exposing enough context to link the request back to an approved business purpose. For IAM teams, that means static role assignments and coarse server-level allowlists are not enough when behavior is dynamic and tool selection is runtime driven.
Practitioners are increasingly moving toward layered controls that combine workload identity, scoped tokens, and request-time policy checks. In mature designs, the server is identified as a workload, but each tool call is evaluated with additional context such as client identity, task intent, approved scope, and session TTL. That aligns with emerging agentic guidance in the OWASP Top 10 for Agentic Applications 2026 and with NHIMG’s AI Agents: The New Attack Surface report, which highlights how often agent activity exceeds intended scope.
- Use workload identity for the server and the agent, not just a shared API token.
- Issue short-lived credentials per task or session, then revoke them automatically on completion.
- Log tool name, client origin, request context, decision outcome, and downstream data touched.
- Apply policy-as-code at request time so scope is judged against current context, not only predeclared roles.
A strong design also separates authentication from authorisation evidence, so IAM can verify the actor while security operations can reconstruct the action path. This guidance tends to break down in heavily federated environments where multiple MCP clients, custom plugins, and inconsistent logging standards prevent end-to-end correlation.
Common Variations and Edge Cases
Tighter MCP governance often increases operational overhead, requiring teams to balance visibility against latency, developer friction, and logging volume. That tradeoff is real, especially where teams are still standardising how agents, clients, and servers are named and classified.
There is no universal standard for MCP telemetry yet, so best practice is still evolving. In some environments, full payload logging is inappropriate because it may capture secrets or regulated content; in others, only metadata is retained, which is enough for identity correlation but not for content reconstruction. The practical middle ground is to capture immutable request metadata, tool allow/deny outcomes, session identifiers, and secret-access events, then store payload details only where policy and privacy rules permit.
Two edge cases deserve special attention. First, shared MCP servers that serve multiple teams can make per-user attribution ambiguous unless every invocation is tagged with the originating client and workspace. Second, agent workflows that chain tools across services can create an “approved first hop, unapproved second hop” problem, where the initial call is legitimate but the follow-on action crosses scope. NHIMG’s Top 10 NHI Issues and Analysis of Claude Code Security both reinforce that governance fails fastest where runtime context is missing. Security teams should assume mcp visibility is incomplete until they can trace the full tool path, not just the server endpoint.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 | Agent tool use hides runtime actions from static IAM views. |
| CSA MAESTRO | CA-02 | MAESTRO addresses agent workflows, tool trust, and execution visibility. |
| NIST AI RMF | AI RMF governance fits accountability for opaque agent-mediated actions. |
Map MCP sessions to task-level identity and enforce scoped, auditable tool execution.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
