Live MCP Tool Call Visibility Before a Security Incident Becomes a Breach Postmortem

Real-time visibility into MCP tool calls is the difference between catching a breach before it completes and reading about it afterward. Most enterprise security teams know their AI agents have MCP connections. They do not know what flows through those connections in the moment it matters.

Why the MCP tool call is the unit of security risk that most enterprise teams are not watching

Each MCP tool call is a discrete runtime event. All of it happens under a specific identity's authority. That is not a configuration state you can audit quarterly. It is an action with consequences that unfold in real time.

Enterprise security teams know they have MCP connections. Obsidian's research frames this as the gap between a connector's existence and its effective authority. A connector sitting in a configuration file tells you what someone intended to permit. It does not tell you what an agent actually retrieved, from where, under whose credentials, at what moment.

The result is architectural, not incidental. MCP servers are deployed without basic authentication or input validation as a norm, not an exception. The tool call itself, the unit where trust becomes action, is the layer nobody is watching. This is the visibility problem that MCP Manager, Usercentrics' AI data-access governance layer, is built to close by instrumenting each tool call as a discrete runtime event under continuous observation.

What a tool call looks like from the inside of a breach, not from a dashboard

The incidents that define this risk are not hypothetical. They share a common thread: traditional security monitoring was not designed to detect any of them. In May 2025, Invariant Labs documented a prompt-injection attack against the official GitHub MCP server. A single over-privileged Personal Access Token configured in the client gave the agent broad access to both public and private repositories. Broad PAT scopes combined with untrusted content in the LLM context. No per-call inspection flagged the anomaly.

MCPoison in Cursor IDE, tracked as CVE-2025-54136, followed a different path to the same destination. An attacker committed a benign MCP configuration to a shared repository and waited for developer approval. The payload came later, silently replacing the trusted configuration. Every subsequent Cursor session executed the attacker's commands. Check Point Research noted that cloud credentials and source code on developer machines fell within reach.

Azure DevOps MCP authentication bypass arrived in April 2026 as CVE-2026-32211 with a CVSS score of 9.1. Microsoft's @azure-devops/mcp npm package had a missing authentication layer on a server handling Azure DevOps work items, repositories, and pipelines. An attacker could access configuration details, API keys, and authentication tokens without valid credentials.

The pattern across all three is the same. Each attack was invisible to firewalls, signature-based endpoint tools, and SIEM alerts. That is not a failure of specific tools. It is a gap in the security model that predates MCP's existence.

Why action chaining makes individual call inspection insufficient and session-level visibility necessary

An agent can execute a sequence of tool calls that chains across systems to reach data it should never touch. Nothing in isolation triggers an alert. The chain reveals the blast radius. Obsidian's tool call monitoring research names this "action chaining" and identifies it as invisible without per-call, per-session visibility.

Agent-to-agent communication compounds the problem. Agent A, with limited permissions, calls Agent B through an MCP tool. Agent B has broad permissions and returns data that neither Agent A nor the user behind it should reach. The permissions model is not exploited. It is navigated. Every hop looks authorized because every hop is authorized, in isolation.

Over-permissioning accelerates the blast radius. The agent is not breaking out of its sandbox. It is walking through doors someone left open.

This changes what visibility must mean. It is not a log of individual events. It is a correlated view of sequences, identities, and data flows across a session. Action chaining across systems and agents requires more than point-in-time inspection of isolated calls. It demands correlated, session-level visibility across tool invocations, identities, and data flows, the real-time per-call and per-session monitoring that a centralized MCP governance platform can provide before the sequence becomes a postmortem.

What legacy controls see and where they stop seeing

The controls gap is structural. Traditional security tooling was built for a different threat surface. MCP tool calls exploit the seams between those tools' coverage areas.

Nightfall's 2026 MCP monitoring checklist is explicit about where each category falls short. Network DLP cannot see inside encrypted MCP sessions. CASB and SWG were built for browsing, not for autonomous tool invocation.

A SIEM receives what gets logged. The absence of a record is not an all-clear. It is a blind spot with a dashboard on top.

IAM sees the credential, not the call. An agent operating under a valid OAuth token looks authorized at every layer except the one that watches what the token is actually used to retrieve. The breach confirms what the token retrieved.

Then there is identity dark matter. Nightfall's checklist cites the problem as framed by Hacker News: AI agents become persistent non-human identities operating outside IAM governance, accumulating access that no one revokes. You cannot revoke what you never knew was granted.

Secrets sprawl makes the perimeter permeable at rest as well. GitGuardian's State of Secrets Sprawl 2026 found 24,008 unique secrets exposed in MCP-related configuration files on public GitHub. Of those, 2,117, or 8.8%, were confirmed valid at the time of scan. The attack surface includes the credentials themselves, sitting in public repositories, waiting.

What real-time tool call visibility actually captures and why post-hoc logs do not substitute for it

Real-time MCP tool call visibility is categorically different from an audit log. An audit log is a postmortem record. The distinction is not about speed. It is about consequence. A log tells you what happened after it is too late to stop. Live visibility gives you the window to intervene.

Obsidian's monitoring research draws the line precisely. Runtime tool call monitoring tells you what it actually did. Those two pictures rarely match. The gap is where the highest-severity risks live.

The four critical data points a monitored call must produce are tool invoked, input parameters, data returned, and invoking identity. You cannot reconstruct what data moved through an unmonitored call after the fact. That information is gone.

A concrete example shows the gap. An agent's configuration may show a standard connector with medium-risk OAuth scopes. The configuration never flagged this as possible. Only the runtime record revealed the actual behavior.

The NSA's May 2026 security advisory, CSI_MCP_SECURITY, identified dynamic tool invocation as a core MCP risk. Agents autonomously call new tools at runtime. Visibility into those runtime decisions is the only layer positioned to catch them before the call completes with consequences.

Behavioral baselining on top of per-call records is what converts visibility into detection. Nightfall's checklist describes the early warning signs: agents that suddenly query tools they have never used, fetch data outside their typical pattern, or chain calls across unrelated systems. Those signals point to indirect prompt injection or compromise. They only emerge from a baseline, not from a single alert threshold.

Why a gateway, a registry, and endpoint inspection each cover a different slice of the attack surface

The debate among practitioners is not which control to choose. It is which combination covers the surface. And the surface is wider than any single layer can see.

The gateway camp argues that centralizing MCP traffic through a gateway is the only practical way to enforce policy across the N-to-N mesh of agents and servers. Nightfall's checklist describes the direct-connection default as an architecture with no choke point for inspection, logging, or policy enforcement. The limit is real. Gateways only protect servers they route. Gateways enforce who and where, not what the data contained.

The registry camp counters that you cannot enforce what you cannot discover. Inventory of every MCP server, every endpoint it touches, and every employee using it is the foundation. Nightfall's checklist calls the inventory a living artifact, not a one-time audit. The limit is equally real. A registry cannot block a call. A gateway can operate without a registry when servers are added by URL. Inventory without enforcement is observation without consequence.

The endpoint inspection camp focuses on where the threats actually start. Local server manipulation and IDE-level prompt injection begin on the endpoint side of the network boundary, where gateway visibility stops. A pure inspection posture misses shadow MCP if agents can bypass the proxy.

SlowMist's MCP Security Checklist covers all three layers as independently necessary categories: server-side API security, client and host security, and multi-MCP scenario security. The meta-conclusion is blunt. Each control category is necessary and none is sufficient. The organization that picks one and calls it done has a gap that is already in the OWASP MCP Top 10.

What a working MCP monitoring program looks like in practice

A working MCP monitoring program is not a list of tools to buy. It is a sequence of capabilities that each depend on the previous one being in place. Inventory enables authentication. Least-privilege enables meaningful anomaly detection.

Step one is inventorying every MCP server as a living artifact. It covers homegrown integrations spun up by individual teams, many authorized through OAuth flows that never passed through IT. Map every connector, every endpoint it touches, and every employee using it. The inventory is not a point-in-time snapshot.

Step two is authenticating and authorizing every connection. Nightfall's checklist and SlowMist's checklist both treat no-auth as an unacceptable baseline inside an enterprise. No MCP-connected agent should ever act under shared credentials, anonymous sessions, or static keys that outlive their purpose.

Step three is enforcing least-privilege scopes per tool, not per server. The identity dark matter problem means agents accumulate access no one revokes. Treat agent permissions like service-account permissions. SlowMist's checklist adds the credential specifics: avoid hard-coded secrets, use key management services, rotate API keys automatically.

Step four is vetting MCP servers before installation and treating updates as new installs. The postmark-mcp npm supply chain incident in September 2025 is the canonical case. A malicious package shipped clean versions before inserting a backdoor. Every MCP server installation is a supply chain decision. Nightfall's checklist calls for scanning tool metadata for hidden instructions and prompt injection patterns before approval.

Step five is centralizing MCP traffic through a gateway. This creates the choke point for inspection, logging, and policy enforcement. Nightfall's checklist identifies this as the only architecture that can enforce policy across the dozens of MCP-driven CVEs disclosed across major implementations.

Step six is logging every tool invocation with full metadata. Which human invoked the agent. Nightfall's checklist notes that most prompt injection and tool poisoning attacks only become visible in retrospect without this record.

Step seven is building behavioral baselines and anomaly detection on top of the log. Agents that query tools they have never used, fetch data outside their typical pattern, or chain calls across unrelated systems are the early warning signs. Nightfall's checklist frames behavioral analytics on MCP traffic as a first-class detection layer, not an afterthought.

Step eight is mapping data flows from MCP to sensitive sources before an incident. Catalog which connectors touch which data categories: regulated PII, source code, customer records, unreleased financials. The blast radius of any future incident should be known in advance, not reconstructed afterward.

Step nine is applying AI-native DLP at the point where data moves. Agent traffic looks like authorized API calls. Sensitive data is semantically transformed before it leaves the perimeter. Exfiltration happens through tool invocations rather than file transfers. Legacy DLP does not operate where the data actually moves.

Step ten is running behavioral baselining that spans sessions. The Deadbugz campaign in September 2026 confirmed that a server behaving normally for multiple calls before activating a payload defeats call-by-call alerting. Session-spanning baselines are the detection layer that closes this gap.

How MCP Manager positions live tool call visibility as governance infrastructure, not a security add-on

The organizations that move fastest with agentic AI are the ones that built the control layer first. The friction that teams blame on security is almost always the absence of a gateway, not the presence of one. MCP Manager, acquired by Usercentrics and integrated with its data governance expertise, functions as the control layer for AI agents operating across the enterprise. It provides the guardrails, access controls, and real-time observability that convert MCP experimentation into production deployment. Its gateway centralizes MCP traffic, creating the inspection and policy choke point that the N-to-N default architecture lacks.

RBAC for AI agents is not about restricting what AI can do. It is about making "what AI can do" a deliberate organizational decision. Every permission is intentional, not inherited. That is a governance position, not a security feature.

Every MCP server added without a registry entry is an identity the organization cannot account for. The identity it cannot account for is the one that gets exploited. A registry-first model addresses this directly by making discovery a precondition for access.

The governance-as-competitive-advantage framing follows. Organizations that treat MCP governance as infrastructure, not compliance overhead, are the ones building agentic AI that regulators and users can trust. The EU AI Act's logging and traceability obligations in Article 12 require high-risk systems to automatically record events to enable auditability. Implementing acts have not yet been published, and no official text references tool-call auditing specifically. Detailed agentic-AI audit requirements remain a developing regulatory area. The organizations that build the observability layer now will not have to retrofit it when the requirements settle.