AI agent identity and data controls for MCP servers

At a glance

What this is: This is a Descope analysis of why MCP servers need identity and data controls, with the key finding that agent access, tool consent, and runtime policy enforcement must all be governed together.

Why it matters: It matters because MCP turns AI agents into active requesters of tools and data, so IAM, NHI, and human access models have to control identity, consent, and data scope at runtime.

👉 Read Descope's analysis of AI data controls for MCP servers

Context

MCP server security depends on treating AI agents as governed requesters, not as anonymous extensions of an application. In practice, the problem is not just connecting a model to a tool. It is establishing who the agent is, what it may call, and what data it may see when the request is made.

Descope's article shows why this is an identity and privacy problem at the same time. Static API keys, broad app-level permissions, and configuration-time access rules do not hold up once agents, tools, and data requests change at runtime. That makes MCP a governance issue for AI agent identity, workload identity, and the data controls wrapped around them.

Key questions

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. Bind it to role, consent, and runtime policy so tool access and data access are evaluated separately at the moment of request. That prevents approved connections from turning into broad downstream trust.

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. Agents can request new tools and new data while a session is active, so configuration-time permissions and coarse app-level roles are too blunt. IAM teams need request-time policy enforcement tied to context.

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. The result is default over-permissioning, weak auditability, and higher exposure of sensitive records. The control gap is not the tool connection itself but the lack of bounded authority at the request level.

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.

Technical breakdown

AI agent identity for MCP servers

MCP servers need a way to distinguish one agentic client from another, because access decisions are only meaningful when the system can bind them to a specific identity. The article describes an AI agent identity vacuum, which is the absence of a dedicated identity model for agents connecting to backend tools and data. Without that layer, every request looks the same, and authorisation collapses into broad application trust. For identity teams, the architectural issue is not just authentication. It is whether the platform can associate agent requests with a durable identity, a role, and a consent record.

Practical implication: create explicit agent identities and bind them to access policy before exposing MCP endpoints.

Runtime authorisation and tool consent in MCP

MCP is dynamic by design. Agents, tools, and requests can change during execution, so configuration-time permissions are too blunt to manage real access safely. The article's runtime access control model relies on OAuth token exchange, existing roles, and policy evaluation at the moment of request. That matters because the same agent may need to send a message, fetch a record, or invoke a downstream service in different contexts. If authorisation is checked only once at setup, the system cannot distinguish legitimate task scope from overreach when the agent asks for a new action mid-flow.

Practical implication: enforce context-aware authorisation at request time, not only when the agent is first connected.

Data privacy guardrails for MCP data flows

The privacy problem in MCP is that an authorised agent can still become an over-privileged reader of sensitive information. The article uses row-level security, masking, and data residency policy checks to separate tool permission from data visibility. That distinction is important: being allowed to call a service does not mean being allowed to read every field returned by it. For organisations handling PII, PHI, or payment data, the governance boundary has to exist at the data layer as well as the identity layer, otherwise an approved agent can still expose regulated information.

Practical implication: pair agent authorisation with field-level or row-level data controls so access and visibility are not treated as the same decision.

NHI Mgmt Group analysis

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.

Static permissions were designed for stable request patterns, and that assumption breaks when agentic systems change scope mid-session. The assumption collapse here is that privilege can be defined once, then safely reused across the life of the session. That assumption fails when the actor can ask for different tools and different data in response to the conversation itself. The implication is that access governance must be designed around runtime context, not provisioning-time intent.

Tool consent and data consent must be split, or AI agents will inherit more authority than the business intended. The article's architecture separates tool access from data protection, which is the right governance pattern for MCP. Many programmes still conflate the two by treating application approval as permission to expose all downstream content. Practitioners need to stop assuming that authorised tool use implies authorised data use.

Field-level privacy controls are becoming part of identity governance, not a separate data-security afterthought. Once AI agents can retrieve and compose sensitive records, masking, row-level security, and residency enforcement become access controls in practice. That means IAM, NHI governance, and privacy teams have to share the same runtime decision model. Practitioners should expect MCP governance to merge identity policy and data policy into one operational control plane.

Runtime control is the named concept this article surfaces: identity decisions made at the moment of use, not at the moment of configuration. That concept captures why MCP breaks older access models. A system can be secure at deployment and still unsafe at execution if the access decision does not follow the request context. Practitioners should treat runtime control as the default design target for MCP-enabled agent flows.

From our research:

• 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.
• As AI agent deployments expand, the governance problem shifts from visibility to control, which makes OWASP Agentic Applications Top 10 a useful next reference for runtime risk planning.

What this signals

Runtime control is the operational test for MCP governance: if the authorisation decision does not happen when the request happens, the system is already behind the actor. That is why identity, consent, and data policy need to converge into one control path for agent-driven workflows.

The governance signal for practitioners is that AI agents are no longer a future-state risk model. With 33% of organisations reporting agents have accessed inappropriate or sensitive data beyond their intended scope, per AI Agents: The New Attack Surface report, the problem is already in production.

Teams that build MCP capability now should expect policy enforcement to become more granular, not less. The more agents touch regulated data, the more field-level masking, row-level filtering, and explicit consent handling become part of the identity programme's baseline.

For practitioners

• 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.
• Use masking and row-level security for regulated records Let the MCP flow retrieve only the minimum fields needed for the task, and mask or redact the rest before the agent can compose a response or trigger a downstream action.

Key takeaways

• MCP server governance fails when identity, consent, and data access are treated as separate problems instead of one runtime control plane.
• The article's core warning is that AI agents become over-permissioned by default unless access is evaluated at the moment of use.
• Practitioners should design for explicit agent identities, separate tool and data controls, and policy enforcement that follows the request context.

Key terms

• MCP server: A server that exposes tools and data to AI systems through the Model Context Protocol. In practice, it becomes part of the identity plane because every request must be tied to an authenticated client, an authorisation decision, and a data boundary.
• Runtime authorisation: An access decision made when the request happens rather than when the system is configured. For AI agents, this is the difference between a safe setup and safe behaviour, because the same actor can ask for different tools or data mid-session.
• Row-level security: A data control that limits which records a user or agent can see inside a dataset. It is especially useful in agentic workflows because tool approval alone does not prevent exposure of regulated fields within otherwise approved records.
• Agent identity: A distinct identity assigned to an AI agent so its requests, privileges, and audit trail can be governed separately from the application or person using it. Without this separation, agent activity is difficult to scope, review, or revoke accurately.

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

👉 The full Descope post shows how runtime identity and privacy controls work together in MCP workflows.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.