MCP & AI Agents: Addressing the 'Identity Dark Matter' in our stacks
Saw the article on The Hacker News about Model Context Protocol (MCP) fueling the next wave of AI agents. The phrase "Identity Dark Matter" really hit home. We're quickly moving from LLMs chatting to agents actually doing things—interacting with APIs, accessing databases, and triggering workflows via MCP servers.
The problem is these agents often inherit permissions that are invisible to standard IAM governance. If an agent is compromised or hallucinates a destructive command, it has the keys to the kingdom. We've started seeing dev teams spinning up local MCP servers (stdio or SSE) that bridge the gap between, say, a Claude desktop app and internal Jira/Postgres instances.
Here’s a snippet of how an MCP client typically requests tool access in Python. If this runs under a user context with high privileges, you have a serious problem:
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
# Parameters to connect to a local MCP server (e.g., file-system access)
server_params = StdioServerParameters(
command="node",
args=["C:\\path\\to\\mcp-server-filesystem.js"]
)
async with stdio_client(server_params) as (read, write):
async with ClientSession(read, write) as session:
# Initializing the session lists available tools
await session.initialize()
tools = await session.list_tools()
print(f"Available tools: {[t.name for t in tools.tools]}")
If an attacker can manipulate the prompt or the MCP server configuration, they can use these tools to exfiltrate data. We need to start treating these agents as non-human identities with strict least-privilege access.
How are you guys auditing MCP connections? Are you inspecting the JSON-RPC traffic, or just relying on standard API gateway logging?
Great post. We're treating AI agents exactly like Service Principals in Azure AD. They get their own Entra ID registrations and Conditional Access policies requiring compliant device status before the agent can query internal APIs. We don't allow local stdio connections to production data; everything must route through a centralized gateway we can audit.
SigninLogs
| where AppId in ("AI-Agent-Gateway-AppID")
| summarize count() by RiskLevel, Result
This visibility is crucial until the vendors build native security controls into the protocol.
From a pentester's perspective, I'm seeing a lot of 'shadow MCP' setups. Devs install an npm package that exposes a file-system MCP server to their IDE agent. If that agent is breached via a prompt injection, the attacker doesn't just get text output; they get a direct shell to the dev's machine. I'd recommend scanning for Node.js processes listening on localhost with suspicious arguments.
ps aux | grep -i 'mcp-server' | grep -v grep
If you find those running in prod environments without approval, shut them down immediately.
Attribution is the nightmare scenario here. Standard logs often just show a generic service account, making it impossible to trace the "intent." We need to enforce context propagation in your MCP servers. Ensure the thread_id is passed along with API calls so we can correlate a destructive action back to the specific prompt.
Example KQL query to investigate anomalous agent activity:
AuditLogs
| where InitiatedBy == "AI-ServicePrincipal"
| project TargetResources, ModifiedProperties, AdditionalDetails
| parse AdditionalDetails with * 'thread_id:' ThreadId:guid *
This visibility is crucial for the post-mortem.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access