MCP blind spots: what changes when agents can call tools?

TL;DR: AI agents using MCP can reach Jira, GitHub, databases and internal APIs through servers that many security teams have never inventoried, according to KonaSense. That creates a blind spot because tool access needs policy, approval and logging at the moment of each call, not after the agent has already acted.

Editorial analysis by NHI Mgmt Group, based on content published by KonaSense: “The Tool Call Is the New Perimeter: Governing MCP for AI Agents”.

Key questions

Q: What breaks when AI agents can chain tools through MCP without tight policy controls?

A: What breaks is the separation between request, authorisation, and execution.

Q: Why does undocumented MCP sprawl increase identity risk?

A: Because every untracked server expands the reachable privilege estate.

Q: What should security teams do when AI agents need access to tools and data?

A: Security teams should treat AI agents as runtime access actors and separate them from static machine identities.

Practitioner guidance

• Inventory every MCP server and connected tool Create and maintain a live register of the servers, tools, owners and underlying credentials that agents can reach across each environment and tenant.
• Enforce per-call authorisation before execution Require allow, block or review decisions to happen before the tool runs, based on the server, requested tool and action context.
• Log every tool invocation with decision context Record the server, tool name, arguments, policy outcome and execution result so security teams can reconstruct agent behaviour later.

Bottom line: MCP turns AI agent integrations into governed access events, which means the security boundary shifts from prompt handling to tool invocation.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →