Model Context Protocol changes how AI agents connect to enterprise tools

At a glance

What this is: Model Context Protocol is an open standard for connecting AI models to tools and data sources, and its main finding is that integration is becoming easier faster than governance is maturing.

Why it matters: For IAM and NHI practitioners, MCP expands the number of machine identities, tool permissions, and secrets that must be scoped, monitored, and revoked without assuming the protocol itself provides control.

By the numbers:

• By early 2025, over 1,000 open-source connectors had been developed.
• Since its launch in late 2024, MCP has seen rapid adoption by major organizations like Google, OpenAI, and Replit.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Astrix Security's analysis of Model Context Protocol and AI agent access risk

Context

Model Context Protocol is a standard for letting AI agents discover and use external tools, but the security problem is that standardisation increases the blast radius of mis-scoped access. In NHI governance terms, every MCP server, client, and host becomes part of the identity surface, with secrets, permissions, and action boundaries all needing explicit control.

That matters because AI agents do not behave like traditional apps. They can chain tool calls, operate with delegated privileges, and move from context retrieval to action without a human in the loop. The result is an access model that resembles workload identity more than user authentication, and most current IAM programmes are still catching up.

The article frames MCP as an enabling layer for integration, which is typical of the current market narrative. For practitioners, the more important question is whether the protocol can be adopted without creating a new class of unmanaged NHI sprawl.

Key questions

Q: How should security teams govern AI agents using Model Context Protocol?

A: Security teams should govern MCP agents as non-human identities with tightly scoped tool permissions, named ownership, and explicit revocation paths. The right control model is per-workflow, not per-platform, because the real risk is not just access to data but delegated action across multiple systems. Audit every tool call with identity context and side effect classification.

Q: What is the difference between MCP integration and normal API integration?

A: Normal API integration usually connects one application to one service with bespoke code and narrow, predefined calls. MCP standardises that interaction so models can discover tools and invoke them through a shared protocol, which improves portability but also expands the governance burden. Practitioners must add identity, scope, and approval controls around the protocol.

Q: Why do MCP-based AI agents create new IAM risk?

A: MCP-based agents create IAM risk because they can act across multiple services with delegated permissions, often without a human approving each step. That turns a single identity into a chain of potential actions, so one mis-scoped token or server can expose far more than the original request intended. Lifecycle control and least privilege become mandatory.

Q: When should organisations restrict or delay MCP deployment?

A: Organisations should restrict or delay MCP deployment when they cannot inventory the connected tools, assign an owner, or prove that secrets and scopes are limited to the minimum necessary. If the business cannot answer those basics, the deployment is creating governance debt faster than it is creating value.

Threat narrative

Attacker objective: The attacker aims to turn trusted AI-tool connectivity into privileged access that can be used for data theft, unauthorized actions, or persistence.

1. Entry occurs when an AI host connects to an MCP server that exposes overly broad tools or reads credentials from configuration files.
2. Escalation follows when the model or operator uses the connected client to invoke actions beyond the intended scope of the workflow.
3. Impact occurs when those tools are used to access sensitive data, modify systems, or exfiltrate secrets at machine speed.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP does not create trust. It redistributes it. The protocol standardises how agents reach tools, but standardisation does not equal governance. In practice, it moves trust from bespoke integrations into a shared execution layer that can amplify any mistake in identity scope, secret handling, or tool exposure. Practitioners should treat MCP adoption as a governance redesign, not an integration convenience.

Ephemeral agent access creates identity blast radius. Once an agent can chain multiple tool calls, the effective blast radius is no longer the original request but every downstream service that the agent can reach. This is a structural issue for IAM because traditional role design assumes relatively stable subjects and predictable workflows. Practitioners should map agent pathways as identity paths, not just network paths.

Access scoping becomes the decisive control for MCP. The most useful control is not whether MCP is used, but whether each server exposes only the minimum tools needed for one task class. That aligns with OWASP NHI thinking around credential exposure and privilege minimisation. Practitioners should measure every MCP deployment by how little it can do by default.

Prompting discipline is not enough when the control plane is identity-aware. Organisations often focus on prompt injection and overlook the fact that a compromised or over-privileged tool path can bypass the prompt layer entirely. MCP increases the need for policy enforcement at the connector, not just at the model boundary. Practitioners should combine model safety controls with NHI governance, or the weaker layer will dominate.

Model Context Protocol is a marker of where the market is heading: agentic integration with security debt attached. The same standard that lowers integration cost also lowers the friction for unmanaged expansion. That means agentic AI programmes will need inventory, ownership, and revocation workflows that look more like NHI operations than software architecture. Practitioners should plan for lifecycle governance before connector sprawl becomes normal.

From our research:

• 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%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• See OWASP NHI Top 10 for the control patterns that map most directly to agent tool misuse and privilege abuse.

What this signals

Ephemeral credential trust debt: MCP adoption will accumulate governance debt wherever teams treat tool connectivity as a plumbing problem instead of an identity problem. The immediate programme-level task is to inventory which agents can act, which systems they can reach, and which secrets make that possible, because unmanaged trust will outpace manual review.

With 96% of technology professionals identifying AI agents as a growing security threat, the governance pressure is no longer theoretical, and the gap will widen as organisations add more connectors and more delegated actions per workflow. Pair protocol controls with the NIST AI Risk Management Framework so agent ownership, monitoring, and escalation paths are explicit.

Teams that already operate a strong NHI programme should extend the same lifecycle discipline to MCP servers and clients, including onboarding, access review, rotation, and retirement. The practical win is not just lower exposure, but faster containment when a connector, token, or tool scope is abused.

For practitioners

• Map every MCP server to an owner and purpose Require each MCP server to have a named business owner, a defined task boundary, and a documented approval path before it is connected to production agents.
• Scope tool permissions per workflow, not per platform Limit each agent to the smallest set of MCP tools needed for one workflow, and separate read-only resources from actions that can change systems or move data.
• Inventory and rotate MCP-related secrets continuously Track every API key, token, certificate, and configuration secret used by MCP clients or servers, then rotate them on a defined schedule and after any exposure event.
• Add approval gates for high-risk tool calls Require step-up review for actions that touch production data, identity records, or administrative settings, especially when the agent can chain multiple requests.
• Log agent-to-tool activity with identity context Capture which agent, which client, which tool, and which downstream service were involved in each action so investigations can reconstruct privilege use and abuse paths.

Key takeaways

• MCP standardises AI-to-tool connectivity, but it also standardises the path by which privilege can be overextended.
• The main security issue is not whether AI can find tools, but whether each tool call is constrained by ownership, scope, and auditability.
• Practitioners should manage MCP components as non-human identities with lifecycle controls, not as neutral integration glue.

Key terms

• Model Context Protocol: An open protocol that lets AI models discover and use external tools and data sources through a standard client-server pattern. In security terms, it turns integrations into a governed execution layer, which means tool scope, secrets, and audit trails matter as much as the protocol itself.
• MCP Server: A service that exposes tools, prompts, and resources for an AI model to use. Security teams should treat an MCP server as a privileged intermediary because it translates model intent into application actions and can therefore expand access if permissions are too broad.
• MCP Client: The component that connects a host or model to an MCP server and forwards requests and responses. It is often the practical enforcement point for trust, because it determines which server is reached, which capabilities are exposed, and how tightly those interactions are scoped.
• Identity Blast Radius: The total set of systems, data, and actions that become reachable when a single identity or token is misused. For AI agents and MCP deployments, blast radius is the most useful way to think about risk because one scope mistake can cascade across multiple tools and services.

What's in the full article

Astrix Security's full article covers the architectural detail this post intentionally leaves at a governance level:

• Client, host, and server interaction patterns for MCP implementations
• How tools, resources, prompts, and services differ in operational behavior
• Practical examples of command parsing and response formatting in real deployments
• Why discovery and bidirectional communication change the security review process

👉 The full Astrix Security article covers the MCP architecture, tool model, and integration mechanics in more detail.

Deepen your knowledge

MCP governance and non-human identity lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is planning agentic integrations, it is a practical place to start.