Most MCP security writing is about the threat getting in — a poisoned tool description, a malicious server, a prompt injection that hijacks an agent. Insider risk is the opposite shape: no attacker, no injected instruction, nobody bypassing anything. Just a person who was legitimately granted a tool, using it for something the grant was never meant to cover. The access is real. The call is real. The only thing wrong is the reason.

Why this isn’t the same problem as the usual MCP threats

Prompt injection and tool poisoning work by feeding the model content it shouldn’t trust. The confused deputy problem works by tricking an agent into using its own real authority on someone else’s behalf. Both need the model to be fooled first. Insider risk needs nothing of the kind — the human at the keyboard already has the authority, already knows what the tool does, and asks for exactly what they want. A scanner that reads tool descriptions for hostile phrasing has nothing to flag, because there’s no hostile phrasing anywhere in the exchange.

It’s also a different question from excessive agency, which is about a tool carrying more capability than any task needs. A narrowly-scoped tool doesn’t fix insider risk either — a refund_order tool that only ever refunds orders is exactly as capable of refunding one to a friend as a bloated one would be. The tool is fine. The question is who’s driving it, and why.

What changes when the access moves into a chat window

Before MCP, a support rep refunding an order clicked through a payment dashboard that logged their login, often required a second person’s sign-off above a dollar threshold, and looked distinctly like what it was: a person taking a specific action in a specific system. A finance clerk pulling a database report opened a BI tool scoped to read-only views, separate from the production database the engineers touched.

An MCP tool collapses that into one interface and one kind of action: a chat message that turns into a tool call. That’s the entire point of MCP, and it’s genuinely useful — but it also means several things that used to be separate systems, each with its own friction and its own log, now look identical from the outside: “the assistant called refund_order” reads the same whether the amount was routine or the recipient was the rep’s own account. The dashboard that used to make a self-refund visually obvious doesn’t exist anymore; there’s just a tool call that succeeded.

What this actually looks like

  • A support tool that can update a customer’s discount field being used to apply that discount to the rep’s own linked account instead of the customer’s.
  • A run_query tool scoped to production data, used to pull a report that has nothing to do with any ticket — a competitor’s contract terms, a colleague’s compensation band, anything the person’s role lets the tool touch but their job doesn’t require touching today.
  • A refund or payout tool used for an amount small enough to sit under whatever threshold used to trigger a manager’s review in the old dashboard — except the tool has no threshold at all unless someone configured one.

None of these need a bug. The tool did exactly what it was built to do, for exactly the person it was built for.

Why the standard MCP controls don’t catch it

OAuth scopes and tool annotations both describe the category of access a tool carries — read vs. write, destructive vs. safe. Neither one has an opinion on intent, because neither one knows who’s actually behind a given call once the grant is issued. A security scan on a server’s tool list, the kind gate’s free MCP security scanner runs, checks whether a tool’s own description is honest and whether it can run arbitrary code — a question entirely separate from whether the person calling a perfectly honest tool should be trusted with it today. Insider risk lives downstream of every one of those checks passing.

What actually narrows it

  • Attribute every call to a real person, never a shared credential. If three people share one API key pasted into a config file, “who did this” is unanswerable by construction. See MCP access control for teams for why shared keys break this before anything else does.
  • Keep tools scoped to what a role actually needs, not what the API allows. A support rep’s refund tool scoped to their own queue of tickets is a smaller surface than the same tool scoped to every order in the system, independent of whether either version would pass a security scan.
  • Put a human in the loop on the specific actions that deserve a second look — a refund above a set amount, a bulk export, anything touching another employee’s record — the same way a dashboard used to force a manager’s click. Human-in-the-loop patterns cover which calls are worth gating this way and which aren’t.
  • Log who, not just what. A record that says “tool called successfully” is useless for this problem; one that says who was signed in, which account was touched, and when, is what turns a suspicion into something you can actually check. MCP observability and audit logs covers what that record needs to hold.
Where gate fits: gate ties every tool call to the person signed in, not a shared key, and gives every tool its own allow / ask / block rule so a sensitive action can require approval regardless of who’s asking. Every call, and every decision, lands in a plain-language log instead of raw JSON — built so a self-refund or an off-ticket query reads as exactly that when someone actually looks, not as an anonymous successful tool call. None of it replaces deciding which actions deserve a second look in the first place; that part is still a judgment call for your team. More on the layered approach on the MCP security page.

The bottom line

Insider risk in MCP doesn’t need a vulnerability, a malicious server, or a tricked model — it needs a legitimately granted tool and a reason to misuse it that nothing in the protocol is built to notice. Scopes, annotations, and security scans all answer what a tool can do. The only things that answer who did it and why are per-person attribution, scoped roles, approval on the actions that matter, and a log someone actually reads.