Unauthorized MCP Tool Calls and Audit Trail Requirements

The Model Context Protocol changes what an AI system is allowed to do rather than only what it can say. Before MCP, a large language model produced text. With MCP, that same model can discover tools, call APIs, read files, trigger workflows, and act across several connected systems in a single session, which changes what a "request" actually means and who answers for it when something goes wrong. That shift sounds small on paper. It isn't. An API call is a known request to a known endpoint, built and reviewed by a developer ahead of time. An MCP tool call is a decision an agent makes on its own, based on a tool description it read moments earlier from a server it may never have talked to before.

The protocol also flips the usual client-server relationship. In the pattern most engineers grew up on, clients ask servers for data and servers answer. The NSA's May 2026 security guidance points out that MCP often runs the other way: servers query, and in some cases execute actions, on behalf of the clients connected to them. That reversal opens attack paths nobody is watching for, because nobody built the watching tools with this direction of traffic in mind.

This is why the usual security stack doesn't catch what MCP breaks. The boundary that matters here isn't the network perimeter and it isn't the API endpoint. It's the trust boundary between what the agent was instructed to do and the tool descriptions it picks up from outside servers, descriptions the agent reads as though they came from its own operator. EDR tools, firewalls, IAM systems, and VPNs were built to watch traffic, credentials, and endpoints. None of them were built to inspect whether a tool description quietly changed the agent's behavior. That gap, between what an agent was told to do and what a tool description tells it to do instead, is where the rest of this problem lives.

The four mechanisms that collapse the trust boundary and produce unauthorized tool calls

Unauthorized MCP tool calls don't happen because an agent glitches or a model hallucinates its way into trouble. They happen because of four structural patterns, each one baked into how MCP is specified and how it gets deployed in practice today.

The first is tool poisoning. A malicious or compromised MCP server can embed instructions directly inside a tool's description field, and the agent reads those instructions as legitimate context, the same way it reads its own system prompt. Microsoft's June 2026 research treats MCP tool descriptions as supply-chain assets, and it walks through a case where an attacker edits the hidden description of a third-party "invoice enrichment" tool so that every future call quietly collects unpaid invoices. The analyst running the tool sees a normal, correct-looking answer. The data leaves anyway. Nothing about the attack looks wrong from the outside, because the agent did what its instructions, poisoned or not, told it to do.

The second is unauthenticated servers. Connecting to an MCP server exposes everything that server can do by default, and a real share of servers running today have no authentication on them at all.

The third is over-scoped permissions. A tool built to read a single table can end up holding write access to an entire database, simply because nobody went back and narrowed its credentials after the first build. Any agent that calls that tool inherits whatever access it was handed, whether or not the task in front of it needs that much reach.

The fourth is token lifecycle gaps. MCP's specification lines up with OAuth 2.1, but it doesn't require token refresh, revocation, or reuse controls at the protocol level. Expiration and rotation requirements appear as recommendations in some drafts, not as rules every implementation has to follow. A stale or reused token can authorize a call that looks, from the log's point of view, exactly like a legitimate one.

These four mechanisms don't operate in isolation. A poisoned tool description is more dangerous on an unauthenticated server. Over-scoped credentials make a stolen token worth more. Each one widens the same trust boundary the opening section described, and together they explain why unauthorized tool calls keep appearing in production rather than staying confined to research papers.

How demonstrated incidents play out in production

None of the four mechanisms above are hypothetical anymore. Each one has already caused documented harm in live systems, not just in a lab someone set up to prove a point.

The clearest case is the Agentjacking incident involving Sentry's MCP server, documented by Tenet Security in June 2026. A single POST request carrying embedded markdown turned a Fortune 100 company's AI coding agent into a tool for pulling data out of its own environment. Tenet found a large number of organizations exposed to the same path and reported a high success rate against Claude Code, Cursor, and Codex alike. Tenet's own name for the pattern, the "Authorized Intent Chain," gets at why standard defenses missed it entirely: the agent was authorized to read Sentry, authorized to run diagnostic commands, and those commands ran inside the developer's own privilege context. EDR, firewall, IAM, and VPN tools all flagged nothing, because nothing in the chain broke any individual rule. When Tenet disclosed the issue to Sentry on June 3, 2026, Sentry acknowledged the problem but stopped short of fixing the root cause, adding a filter to block one specific payload string instead. That response treated the symptom and left the underlying authorization gap standing.

A second incident shows the same fragility from a different angle: the supply chain itself. The Miasma Worm, tracked as TeamPCP and attributed to UNC6780, spread through adversarial MCP configuration files planted across 73 GitHub repositories in June 2026, including Microsoft Azure's own azure/durabletask project. Any developer who opened one of those repositories in a vulnerable IDE triggered a credential-harvesting payload. There was no running server to compromise here, no endpoint to breach. The dangerous asset was a configuration file sitting in a repository, and it became an active threat the moment a trusted IDE loaded it automatically.

Taken together, these two incidents cover different mechanisms from the same root list: tool poisoning and authorization collapse in the Sentry case, the supply-chain vector in the Miasma Worm case. Both happened in production, against real organizations, within the same month. That timing matters less than what it confirms: every mechanism named in the previous section has already left the whiteboard.

Blast radius of a single tool call

A single unauthorized tool call rarely stays single. In a multi-agent chain, one agent's output feeds directly into the next agent's input, and content planted in that output can steer how later agents interpret everything that came before it. This lets an attacker hijack the control flow across a whole sequence of chained MCP processes without tripping a single alert anywhere along the way.

The Sentry incident is the clearest evidence of this dynamic in practice. Every individual tool call in that chain was, on its own, authorized. The harm only existed in the sequence of calls taken together. An audit system that checks whether each call was permitted, one at a time, would have approved the entire chain and missed the attack completely.

Scale makes this worse. Credential hygiene across non-human identities, the agents, service accounts, and API keys running through these systems, is weak across the board: most of these identities aren't rotated within recommended timeframes, and most organizations have no formal process for revoking an API key once the agent it belonged to gets decommissioned. A compromised agent identity can stay valid for a long stretch of time after the incident that compromised it has already been found and supposedly closed.

Enterprise leaders already know this is the sticking point. The KPMG Q4 2025 AI Quarterly Pulse Survey asked large-enterprise leaders what they needed most from agent deployments, and security, compliance, and auditability came back as the top requirements. At the same time, the complexity of orchestrating multiple agents together has become the main thing stopping companies from moving past pilots into full production.

Without audit logs that capture the full sequence of tool calls, not just whether each one individually passed a permission check, incident response in this environment turns into guesswork. Investigators can't reconstruct the chain of events, can't say with confidence which agent did what, and can't show a regulator or auditor that the system behaved the way it was supposed to.

MCP specification authentication status

The July 2026 revision of the MCP specification closes real gaps in authentication. It leaves authorization and token lifecycle management up to whoever builds the deployment, which is precisely where most unauthorized tool calls start.

What the July 28, 2026 spec actually requires is specific. MCP servers are now formally classified as OAuth 2.1 resource servers, a classification first introduced in the 2025-06-18 spec and further tightened in the July 28, 2026 revision. Servers must implement OAuth 2.0 Protected Resource Metadata, under RFC 9728, so that a client can automatically find the correct authorization server instead of guessing or hardcoding it. Clients must implement Resource Indicators under RFC 8707, a requirement first set in June 2025 and carried forward unchanged into the July 2026 spec, so that a token is tied explicitly to the server it was meant for. That stops a malicious server from grabbing a token that was supposed to go somewhere else.

Alongside the spec itself, Enterprise-Managed Authorization, which stabilized on June 18, 2026, lets organizations control MCP server access centrally through whatever identity provider they already run. Anthropic, Microsoft, and Okta are among the companies that have adopted it, and for end users it means zero-touch setup on first login, with no separate OAuth flow to manage for every app they connect.

All of that narrows the front door. None of it touches what happens once an agent is already inside. Authentication decides whether an agent can reach a server in the first place; authorization decides which specific tools on that server it's allowed to call, and connecting to a server still exposes everything on it unless someone deliberately locks that down. The spec doesn't require token refresh, revocation, or reuse controls at the protocol level, so those decisions still fall to whoever builds and runs the deployment.

That leaves organizations responsible for the controls the spec doesn't supply: scoping permissions down to the individual tool, issuing credentials just in time rather than up front, and enforcing limits at runtime rather than only at connection time. The spec is real progress on the perimeter. The interior, where tool poisoning, over-scoping, and token misuse actually happen, is still something every deployment has to build for itself.

What a complete audit trail must capture

An audit trail that only records whether a session was authenticated and whether a token was present can't surface any of the four root-cause patterns described earlier. Catching them requires logging at the depth of the individual tool call, across the entire delegation chain, not just at the session boundary.

Each mechanism needs its own specific capture point. Against tool poisoning, the log has to record the exact tool description that was in effect at the moment of each call, in addition to the name of the tool that was invoked. The poisoning event is the gap between the description a human approved and the description the agent actually executed against, so without a snapshot of that description, the log shows nothing more than a call to a tool that was, on paper, approved.

Against unauthenticated servers, the log needs the server's identity, the authentication mechanism it used (or the fact that it used none), and the authorization scope it asserted for that call, not just which endpoint got hit.

Against over-scoped permissions, the log needs to show what a tool was scoped to access set against what it actually accessed during that call. A log that records only the tool's name hides that gap completely.

Against token lifecycle gaps, the log needs to timestamp when a token was issued and when it expires against every call that token authorizes, flag any case where a token gets reused outside its intended scope or past its intended lifetime, and record whether rotation happened before the token was used again.

The Sentry incident adds one more requirement on top of these four: sequence. The audit trail has to reconstruct the full ordered chain of tool calls, both within a single agent's run and across multiple agent invocations, rather than treating each event as an isolated record. That incident caused real harm that was only visible once the calls were strung together in order, so any logging that evaluates calls one at a time, in isolation, misses it entirely.

Attribution matters just as much as sequence. Every tool call needs to carry the identity of the specific agent instance that made it, in addition to the user session that kicked off the chain. Without that, there's no way to answer the basic question of which agent did what, especially once an organization's non-human identity population runs at tens of agents for every human user it employs.

Any of this is only as good as its integrity. Logs have to be tamper-proof and exportable, because a log that the same system being audited can quietly alter gives nobody, not security teams, not auditors, not regulators, any real assurance about what happened.

The way to pull all of this together is tracing across the entire delegation chain, from the user, through the agent, through the MCP client, to the MCP server, to the tool, and on to whatever downstream resource it touches. That end-to-end trace is what lets a security team reconstruct any incident after the fact and lets the organization hand over the evidence chain regulators expect to see.