MCP: A “USB-C” for AI Is Here: Who’s Managing the Identities Behind It?

In late 2024, Anthropic introduced its open-source Model Context Protocol (MCP) – a universal plug for AI agents and large language models. Think USB-C, but instead of charging your phone, it’s charging up AI agents with access to GitHub, Slack, Postgres, internal file systems, and pretty much any data source and SaaS app you’d want to wire into an LLM.

It’s elegant. It’s extensible. It’s open source.

But with great connectivity comes… a mess of non-human identities (NHIs).

What MCP Actually Does

MCP uses a simple client-server setup: the AI agent connects to a tool server (like Slack or GitHub) over a secure channel using JSON-RPC. The server handles permissions and only exposes what the agent is allowed to access — often running locally or in a secure environment.

In more simple terms, the new MCP protocol provides a standard way for AI models to connect with external systems. Instead of building ad-hoc integrations, developers can now spin up small “servers” that expose tools (like databases or SaaS apps) over a secure protocol. On the other end, an AI “client” – the agent – initiates a connection and requests access for those tools.

For example, if you are a developer, your AI agent can now:

• • Create or read GitHub pull requests

• • Retrieve entries from Postgres

• • Summarize files from your local project

• • Send Slack messages

Each of these actions is made possible through some combination of:

• • OAuth tokens

• • API keys

• • Service accounts

In other words, actions are powered by an NHI, and each NHI is an identity worth securing.

The Hidden Layer: NHI and Secret Sprawl

What’s missing from the recent MCP hype is what’s happening underneath the protocol layer.

MCP doesn’t replace authentication – it just makes it easier to connect. Which means every connection still requires secrets. Every tool server still needs credentials. And every AI agent becomes a de facto NHI with its own entitlements and access patterns.

So the security questions pile up:

• • Who owns the AI agent once it’s connected to 5+ toolchains?

• • Are its credentials stored securely?

• • Are they short-lived? Rotated? Scoped to least privilege?

• • What happens when the developer leaves and the token stays behind?

MCP recommends OAuth 2.1 for client authentication and supports access + refresh tokens. This allows AI clients to use standard authorization flows to obtain scoped tokens, minimizing the need for hardcoded secrets, but it still relies on external systems to enforce rotation and expiration.

Servers can enforce scopes, and some even encourage “read-only” usage patterns (Postgres, for example). Still, there’s no built-in vaulting, no native lifecycle management, and nothing stopping a developer from hardcoding an API key for their AI assistant into a config file.

Let’s be real: plug-and-play is amazing. But when it’s AI agents we’re plugging in, every new connection introduces a new NHI with its own blast radius.

AI Agents Are NHIs: Treat Them That Way

MCP doesn’t define the concept of an identity. There’s no “agent profile,” no ownership tagging, no centralized view of what agents exist or what systems they touch.

But in practice? Every AI agent is a non-human identity. It logs into systems. It holds credentials. It makes privileged decisions. And it may be doing that 24/7 across dozens of environments.

The best-case scenario is scoped tokens with short TTLs and clean audit logs.

The worst-case? A high-privilege bot that can silently read or modify production systems without anyone noticing—until it leaks or misfires.

Where This MCP Craze Is Going

OpenAI’s adoption of MCP kicked this into high gear. Microsoft’s Azure AI agents are getting MCP-compatible. AWS, Stripe, and Slack all have connectors live or in progress. The new standard is moving fast – and AI agent proliferation is going with it.

That’s a good thing.

But the rise of MCP is accelerating the creation of AI-driven NHIs at a scale we haven’t fully reckoned with.

So before we let every dev spin up a Claude or GPT-powered assistant with GitHub and database access, it’s worth asking:

• • Is this identity visible in your IAM system?

• • Are its credentials rotated?

• • Does it have an owner?

• • And if not – who’s accountable when it acts?

Because this isn’t just an interface layer. It’s an identity explosion.

Interested in learning more? Speak to an Entro expert.