TL;DR: AI agent rollouts through Model Context Protocol create a new access-control problem because shared credentials and broad tokens can expose GitHub, Slack, APIs, and databases to the wrong users, according to Highflame. Safe adoption depends on identity-aware policy enforcement at the tool-request layer, not just on giving agents more connectivity.
NHIMG editorial — based on content published by Highflame: Securely Rolling Out Claude Cowork Across Your Organization
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.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: What breaks when AI tools are exposed through loosely governed MCP servers?
A: Loose governance lets model-driven tools cross from context retrieval into state-changing actions without enough oversight.
Q: Why do AI agents need their own identity instead of borrowed human credentials?
A: AI agents need their own identity because borrowed human credentials destroy auditability, make revocation imprecise, and expand blast radius.
Q: What signs show that MCP permissions are too broad?
A: The clearest signs are shared tokens, server-wide access grants, and a lack of tool-level logging or approval separation.
Practitioner guidance
- Define tool-level policy boundaries Separate read, write, and destructive MCP actions into distinct policy decisions so the agent cannot inherit a broad server-wide entitlement.
- Bind every request to human identity Require authenticated user context, group membership, and target server identity before any tool call is forwarded.
- Replace shared tokens with scoped controls Phase out broad access tokens and static API keys where MCP servers handle sensitive systems.
What's in the full article
Highflame's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step policy examples for differentiating support, engineering, and sales permissions at the MCP tool level
- Gateway and runtime enforcement flow for binding agent requests to authenticated user context
- Audit logging fields that support incident investigation and entitlement review
- Implementation details for blocking destructive actions while preserving read-only agent workflows
👉 Read Highflame's analysis of secure Claude Cowork rollout with MCP access controls →
MCP server access for AI agents: what IAM teams need to enforce?
Explore further
Identity-aware MCP control is now a governance requirement, not a convenience feature. MCP collapses multiple systems into a single agent-mediated access path, which means the old assumption that application permissions alone define safe use no longer holds. The same agent can bridge GitHub, Slack, APIs, and databases, so the identity layer must decide what the human is actually entitled to do in each context. For practitioners, the question is no longer whether to connect agents, but how to stop connectivity from outrunning entitlement.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to Astrix Security.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
A question worth separating out:
Q: How should teams control AI agent access to downstream tools?
A: Teams should treat agent access as a bounded runtime grant, not a generic application permission. Each tool call should be covered by explicit policy, monitored for scope drift, and revocable without depending on a human to notice the problem later. If the agent can chain actions across systems, the control boundary must exist before the chain starts.
👉 Read our full editorial: Identity-aware MCP access controls define safe AI agent rollout