Notifications
Clear all
Topic starter
24/06/2026 8:40 pm
TL;DR: MCP turns AI agents into active tool users, so static API keys, long-lived tokens, and coarse permissions become blast-radius risks when agents query databases, update systems, and call SaaS APIs, according to Permit.io. The real issue is not authentication alone but runtime authorization that matches delegated, context-sensitive, and relationship-aware access.
NHIMG editorial — based on content published by PermitIO: Authorization Strategies for Model Context Protocol (MCP)
By the numbers:
- 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.
Questions worth separating out
Q: How should security teams govern agent access in MCP environments?
A: Treat MCP access as runtime authorization, not just authentication.
Q: Why do static API keys create risk for AI agents?
A: Static API keys create risk because they grant durable authority to a non-durable actor.
Q: What do security teams get wrong about OAuth in agentic systems?
A: They often treat OAuth as the full answer to access control.
Practitioner guidance
- Separate authentication from authorization decisions Use OAuth 2.1 for delegation, but route every MCP action through a policy engine that evaluates user, tool, resource, and context before execution.
- Replace standing credentials with task-scoped access Eliminate long-lived API keys and persistent tokens for agent workflows, then expire access automatically when the request or session context changes.
- Model delegation relationships explicitly Represent owner, shared-with, and acts-on-behalf-of relationships in policy so the agent can only reach data and actions justified by the current relationship.
What's in the full article
PermitIO's full blog covers the operational detail this post intentionally leaves for the source:
- Concrete policy examples for MCP servers, APIs, and data layers that show how RBAC, ABAC, and ReBAC are enforced in practice
- Implementation detail on how local policy decision points reduce latency while still supporting real-time authorization
- Step-by-step discussion of zero standing permissions for agent workflows, including token scoping and expiration patterns
- Practical deployment guidance for combining OAuth 2.1 with policy enforcement without exposing raw credentials to agents
👉 Read PermitIO's analysis of MCP authorization strategies for autonomous agents →
MCP authorization and agent permissions: what changes for IAM teams?
Explore further
25/06/2026 5:23 am
Zero standing permissions is the right baseline for MCP because ambient authority is the failure mode. MCP agents are not passive clients. They can discover tools, combine actions, and keep operating after the original context has shifted. That makes long-lived credentials a governance failure, not just a convenience issue. The implication is that security programmes need to stop treating agent access as durable entitlements and start treating it as ephemeral, task-scoped authority.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
A question worth separating out:
Q: How do organisations reduce blast radius for MCP deployments?
A: Use zero standing permissions, scope access per request, and expire credentials automatically when the session ends or context changes. Pair that with centralized policy enforcement so the same access rule applies across tools, APIs, and data layers instead of being duplicated in each system.
👉 Read our full editorial: Mcp authorization strategies for autonomous agents need runtime control
