AI Security
AI agents pose identity crisis: Why MCP security hinges on stricter permissions, not just patches
As AI agents become long-lived components rather than temporary scripts, the real security problem isn't the protocol—it's preventing them from inheriting excessive permissions from the humans who spawn them.
The New Stack
The shift from infrastructure to permissions#
Since Anthropic's Model Context Protocol entered production in late 2024, adoption has exploded across the industry. Microsoft, Google, and OpenAI all embraced it. The Linux Foundation assumed governance. Today MCP sits at the critical intersection between AI agents and the tools and data they access—making it a prime security target.
Yet the real vulnerability isn't where most teams initially looked. According to the SANS 2026 Identity Threats Survey of over 500 security professionals, 76 percent of organizations have seen a surge in non-human identities, and 74 percent rely on AI systems using persistent credentials for autonomous operation. The catch: fewer than 40 percent deploy even basic safeguards like approval workflows, sandboxing, or audit logging.
The root cause keeps surfacing in incident after incident. A May 2025 breach of the GitHub MCP server exploited prompt injection not because of a traditional bug, but because the personal access token granting access was scoped far too broadly. Weeks later, an Asana integration flaw allowed cross-tenant data leakage due to missing permission boundaries. The pattern: servers granted more access than their assigned tasks demanded.
The credential sprawl problem#
Most teams treat MCP integration like any other API connection—install it, trust the defaults, and move on. This approach fails because AI agents operate under fundamentally different constraints than human users or traditional services.
The question that should drive every integration decision rarely gets asked: Why does this particular server need access to something it never actually uses? And critically: does that access remain necessary today, not just when credentials were provisioned?
According to GitHub's Engineering Blog, the emerging best practice involves several layers:
- Each agent instance should have its own isolated secrets tied to a specific task
- All requests should be limited to the authenticated user context
- Authorization must enforce per-action rules rather than assuming blanket trust after login
- Swap static, long-lived tokens for dynamic, short-lived credentials generated just-in-time
