MCP server security exposes the blind spot in agent governance

At a glance

What this is: This is an analysis of MCP server governance and its key finding is that the protocol layer becomes a blind spot when agents can reach tools, data, and credentials without sufficient discovery or runtime control.

Why it matters: It matters because IAM, NHI, and agentic AI programmes now have to govern tool access, purpose, and auditability at the protocol layer, not just manage identities and static permissions.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Trust3's analysis of MCP server security and agent governance

Context

MCP, or Model Context Protocol, is the layer that lets AI agents discover tools, call APIs, and exchange results with enterprise systems. The security problem is that existing IAM controls were built around human users and fixed service identities, while MCP turns access into a runtime decision made by the agent.

That means policy has to follow the action, not just the account. If an agent can inherit credentials, choose tools, and reach data sources without purpose-bound enforcement, then access review alone cannot explain what the system actually did or why it did it.

For identity security teams, the issue is not whether MCP exists in the stack but whether it is governed as a privileged execution layer. In most environments that starting position is still immature rather than exceptional.

Key questions

Q: How should teams govern AI agents that use MCP?

A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.

Q: Why do MCP servers create new visibility gaps for IAM teams?

A: MCP servers create visibility gaps because tool invocation happens inside AI-mediated sessions that span multiple clients and often lack a clean audit trail. IAM teams may know the server exists, but not which tool was called, from which client, or whether the call matched the approved access scope. That makes runtime evidence essential for governance.

Q: What breaks when AI agents are connected directly to enterprise systems?

A: Direct connections often break auditability, predictable authorisation, and operational containment. If an agent can act without a governed mediation layer, teams may lose visibility into what it accessed, what it changed, and whether those actions were permitted. That creates both security risk and accountability gaps.

Q: What should organisations do about shadow AI in MCP environments?

A: Organisations should discover unmanaged agents before expanding gateway policy. If an agent is not registered, no amount of RBAC at the gateway will fully govern it. Discovery, registration, and enforcement need to be part of the same operating process so hidden access paths do not bypass the control plane.

Technical breakdown

Why MCP changes the access control problem

MCP standardises how an AI agent discovers tools and sends requests, but standardisation does not equal governance. The protocol sits between the agent’s reasoning and the enterprise resource, so a valid credential can still produce an invalid action if the request violates purpose, data sensitivity, or task scope. That is why packet inspection and user-centric authorisation miss the real decision point. The important control boundary is no longer just identity authentication, it is whether the agent is allowed to perform that specific tool action in that specific context.

Practical implication: Treat MCP as an enforcement boundary and not only an integration pattern.

How shadow AI agents become an NHI governance problem

When business teams connect unsanctioned agents to data sources through MCP servers, the result is shadow AI with non-human identities that do not appear in normal inventory processes. These identities can inherit permissions, invoke tools, and move data without the review cadence used for humans or traditional service accounts. The governance gap is discovery first, then classification, then control. Without all three, security teams cannot distinguish sanctioned agent behaviour from unapproved runtime access.

Practical implication: Build continuous discovery for agents, servers, and tool permissions before attempting policy enforcement.

Purpose-based access control for tool calls

RBAC is too coarse when access should vary by task rather than by role. Purpose-based access control ties permissions to declared intent, so an agent working one job cannot quietly reuse the same reach for a different business purpose. In MCP environments, that means scoping access per request, binding credentials to a single integration, and expiring use when the task ends. This is the closest practical fit for least privilege in agentic systems because the control follows intent and not just identity.

Practical implication: Use task-scoped controls and auto-expiring grants for every MCP-connected tool.

NHI Mgmt Group analysis

MCP server security is really a governance problem about delegated action, not model output. The article correctly separates what the model says from what the agent does. That distinction matters because access risk now emerges when an identity can call tools, retrieve data, and trigger transactions at runtime. The field needs to stop treating agent security as a content-safety extension of AI governance and start treating it as a privileged execution problem. Practitioners should frame MCP as part of the identity control plane, not as a sidecar to application security.

Shadow AI is the new unmanaged NHI estate for agentic environments. The article shows how quickly unreviewed agents and servers can appear outside formal security oversight. That is the same structural problem identity teams have long faced with service accounts and API keys, but now the blast radius expands because the agent itself selects tools and data paths dynamically. Runtime governance gap: This is the specific concept the market needs to sharpen, because the control failure is not only missing inventory but missing visibility into what the identity can do after discovery. Practitioners should expect agent inventories to become as operationally important as secrets inventories.

Traditional IAM assumes access can be judged at provisioning time, and that assumption is breaking. Purpose, scope, and timing are no longer stable enough to evaluate once and forget. An MCP-connected agent can hold valid credentials and still perform an action that should never have been permitted for that purpose. The implication is that identity governance must move from static entitlement review to action-level governance, where tool use, data use, and credential use are all part of the control decision.

Least privilege in MCP environments is only meaningful when credentials are isolated per task and per tool. Shared service accounts and broad inherited access create lateral movement paths the moment one agent or server is compromised or misbehaves. The article’s emphasis on scoped credentials points to the right model, but the deeper point is that privilege needs to be expressed in the protocol layer as much as in the directory. Practitioners should expect NHI governance, PAM, and data access controls to converge around task-bound enforcement.

AI agent security is collapsing into a single operating question: who can act, on what, for how long, and under whose purpose. MCP exposes that question directly because it is the conduit through which agents touch enterprise systems. The article reinforces a broader industry shift toward runtime authorisation, continuous audit, and purpose-aware access decisions. Security teams that still separate AI governance from IAM will keep missing the place where risk is actually created, and that is the operational gap to close.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• From our research: While 71% of IT teams have been advised on AI agent data access, only 47% of compliance teams, 39% of legal teams, and 34% of executives have the same visibility, according to AI Agents: The New Attack Surface report.
• From our research: See the OWASP Agentic Applications Top 10 for the control patterns that map most directly to this governance gap.

What this signals

Runtime governance gap: MCP makes agent actions visible only if the organisation can correlate identity, purpose, tool use, and data movement in one place. That is why agent governance is becoming an operating discipline, not a policy document, and why the OWASP Agentic AI Top 10 is increasingly relevant to security architects.

With 92% of organisations saying AI agent governance is critical but only 44% having policies in place, the gap is already wider than most IAM programmes assume. Teams that manage service accounts, secrets, and human access separately will need to converge those controls around runtime authorisation and audit.

The next programme decision is whether MCP is treated as a managed identity boundary or as an uncontrolled integration layer. If it stays informal, shadow AI will keep expanding faster than recertification cycles can track, and the evidence trail will remain incomplete when an incident happens.

For practitioners

• Inventory every MCP connection and AI agent Create a live register of sanctioned and unsanctioned agents, the MCP servers they touch, and the tools they can invoke. Include who built the agent, what data sources it can reach, and whether the connection has been reviewed.
• Bind access to declared purpose Replace broad role grants with task-scoped policy that evaluates intent per request, then expires access when the task ends. Apply this to high-risk data sources first, especially where agents can join datasets or trigger downstream actions.
• Scope credentials per tool and integration Stop reusing shared service accounts across multiple agents or MCP servers. Issue dedicated credentials for each tool path, remove standing access, and make revocation automatic when an agent or workflow is retired.
• Monitor runtime behaviour, not just configuration Log every tool call, credential exchange, retrieval, and data flow, then compare the activity to expected patterns. Use this to detect unusual data volumes, tool chaining, or actions that do not match the declared task.
• Add a kill switch for misbehaving agents Ensure operators can immediately suspend an agent, revoke its credentials, and block further MCP calls when behaviour becomes suspicious. Containment has to happen before the agent completes the task chain.

Key takeaways

• MCP shifts agent risk from model output to runtime action, which means IAM controls have to evaluate purpose, tools, and data access together.
• The biggest governance failure is visibility, because organisations cannot secure agents they have not discovered and cannot audit actions they never logged.
• Purpose-based, task-scoped access is the practical control pattern for MCP, but it only works when credentials, monitoring, and revocation are all runtime enforced.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Intent-Based Access Control: An access control model that evaluates not just what an agent is requesting, but the inferred intent and context behind the request — granting or denying access based on whether the action aligns with the agent's declared purpose.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.

What's in the full article

Trust3's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step MCP governance sequence for discovery, policy definition, monitoring, and enforcement across connected agents.
• Examples of how Trust3 maps purpose-based access control to Snowflake, Databricks, and BigQuery request flows.
• Implementation detail on tamper-evident audit trails, kill switches, and runtime guardrails for misbehaving agents.
• A comparison of Trust3, Zenity, Palo Alto Networks, and Immuta from an operational control perspective.

👉 Trust3's full article covers the MCP control sequence, runtime enforcement details, and platform comparisons.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM, PAM, or identity governance programme, it is worth exploring.