MCP access reviews: who can still call what

A tool nobody has called in three months still holds a live credential to the ERP. Nobody decided to keep it. It was added for a pilot, the pilot ended, and removing it was never on anyone’s list.

Access to MCP tools only grows. Teams add tools, groups and AI assistants, and nobody takes anything away, because nobody is asked to. Reviewing access is the last stage of the MCP governance framework, and it’s the one that keeps the other seven honest.

Why MCP access only grows

Each addition has a reason at the time. A team needs a new tool for a project. A group is given access to a server so a rollout can move faster. Someone connects a new AI assistant to try it. Each one is small, and none comes with an end date.

Removal has no trigger. People change roles, projects finish and trials end, but the tools, the group memberships and the assistants stay connected until someone asks whether they should.

Why the usual review changes nothing

1. One spreadsheet goes to everyone. A company-wide list of servers and callers gets approved without being read, because no single owner recognizes most of it.
2. There’s no usage on the page. Without call counts, an owner can’t tell a tool that’s used daily from one nobody has touched, so they keep both.
3. Silence means keep. If an owner doesn’t answer, access stays, and the review removes nothing.
4. Only people are reviewed. AI assistants and agents connected for a trial last year can still be calling tools today, and nobody lists them.
5. Tools and callers are reviewed separately. A tool nobody can call is clutter. A caller who never uses a tool is open access for no reason. You only see both by looking at them together.

What it costs

Every unused tool with a live credential is a way into a system of record. If an agent, an assistant or a leaked token reaches it, the damage is limited only by what that credential can do.

Auditors ask the same question, and the honest answer is often “we don’t know who still uses it.” That turns into a finding, then a scramble, then a one-off cleanup that starts drifting again the next week.

What to fix first

1. Send each owner only their own servers. A short list they recognize gets read.
2. Put real usage on every line. An owner who sees no calls in 90 days can remove access in one click instead of guessing.
3. Review tools and callers together. Show which people, groups and assistants call each tool, and how often.
4. Remove anything not confirmed by the deadline. Make keeping access the action that needs a click.
5. Include AI assistants and agents. Review them alongside people, with the same usage numbers.

The guide to building an MCP tool access review has the prompts that build each step.

Where access review fits

A review only works if every call is tied to a real person. When MCP services run on a shared service account, the log shows the account, and nobody can say who needs access. Dynamic Authentication carries the user’s own identity through each call, which is what makes a review answerable. Your MCP service works. But can you answer this question? covers how.

“As we roll MCP out, I don't want end users thinking about which system they're authenticating to or what tools they have access to. Tray's Dynamic Authentication lets us scale agents across the enterprise without compromising on user-level permissions.”

The review also closes the loop with the first stage. Finding shadow MCP brings unmanaged servers into view, and a regular review stops managed ones from drifting back out of it.