Notifications
Clear all
Topic starter
06/07/2026 9:39 am
TL;DR: MCP server deployments fail when AI agents lack dedicated identities, coarse app-level access over-permissions tools by default, and static permissions cannot keep pace with runtime data requests, according to Descope and Skyflow. The governance problem is not only authorization, but proving who or what is allowed to request data at the moment access happens.
NHIMG editorial — based on content published by Descope: Build AI data controls for MCP servers with Descope and Skyflow
Questions worth separating out
Q: How should security teams govern AI agents that connect to MCP servers?
A: Treat each agent as a distinct identity, not as a generic application session.
Q: Why do MCP servers create new access control problems for IAM teams?
A: MCP servers change access from a static setup problem into a runtime decision problem.
Q: What breaks when AI agents rely on coarse app-level access in MCP environments?
A: Coarse app-level access hides which agent is asking, which tool is in play, and which data is actually needed.
Practitioner guidance
- Create dedicated identities for MCP-connected agents Map each agent or agent class to a distinct identity, role, and consent record so the platform can distinguish approved behaviour from ambient application access.
- Separate tool authorisation from data visibility Use different controls for API invocation, row access, and field exposure so a permitted tool call cannot automatically reveal sensitive customer or payment data.
- Enforce runtime policy checks at request time Apply context-aware evaluation when the agent asks for a tool or record, and require the decision to reflect role, purpose, and data classification at that moment.
What's in the full article
Descope's full article covers the implementation detail this post intentionally leaves for the source:
- OAuth token exchange flow between Descope and Skyflow for runtime agent requests
- Step-by-step mapping of identity roles to application roles for differential PII access
- Examples of row-level security and masking rules applied to marketing, support, and payments use cases
- How the token vault stores tool credentials for agent-initiated actions
👉 Read Descope's analysis of AI data controls for MCP servers →
MCP server identity and data controls: what IAM teams need now?
Explore further
06/07/2026 9:54 am
MCP security is really a governance problem about who the agent is allowed to become at runtime. The article correctly shows that a model-to-tool connection is not the same as a governed identity relationship. Once an AI agent can request tools and data dynamically, the control question shifts from login success to bounded authority. Practitioners should treat MCP as an identity boundary, not a transport detail.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: How can organisations reduce sensitive data exposure in MCP workflows?
A: Use row-level security, field masking, and policy checks alongside authentication. That way the agent can complete its task without seeing unnecessary PII, PHI, or payment data. Organisations should assume tool approval and data approval are separate decisions and design the workflow accordingly.
👉 Read our full editorial: AI agent identity and data controls for MCP servers
