TL;DR: Model Context Protocol standardises how AI agents discover and use tools, resources, and prompts across hosts, which shifts integrations from bespoke build work to governed capability surfaces, according to Frontegg. That makes entitlement scoping, auditability, and confirmation gates the real control plane for agent access, not the transport layer.
At a glance
What this is: This is an analysis of how Model Context Protocol changes the governance model for AI agent access to tools, resources, and prompts, with the key finding that capability surfaces become the control point.
Why it matters: It matters because IAM, PAM, and NHI teams now need to govern what agents can discover, call, and confirm, rather than treating integration as a purely engineering problem.
Context
Model Context Protocol, or MCP, standardises how AI agents discover and use tools, resources, and prompts across hosts and models. That shifts the security question from bespoke integration handling to governed capability exposure, because the agent now operates against a reusable contract instead of a one-off connector.
For IAM and NHI programmes, the risk is not that an agent can connect, but that it can discover too much, call too much, or act too freely once connected. The governance problem becomes entitlement scoping, confirmation gates, logging, and tenant-aware visibility for each capability surface.
Key questions
Q: What breaks when agents can discover capabilities before entitlement checks are applied?
A: Discovery becomes an access event, not just a convenience feature. If a host can enumerate tools before the platform checks entitlement, the agent may expose workflows, data sets, or prompts the user should never learn exist. That expands the attack surface and makes policy dependent on what the agent can see, not only what it can execute.
Q: Why do MCP-based agent integrations increase governance risk when confirmations are optional?
A: Optional confirmations let the agent complete high-impact actions without a clear friction point before execution. If deletes, refunds, or production changes are reachable through the same capability path as low-risk actions, the control plane cannot distinguish routine use from irreversible change. The result is weaker accountability and a larger blast radius for misuse.
Q: How should IAM teams decide which MCP capabilities need tighter approval?
A: Start with the actions that are irreversible, data-bearing, or tenant-scoped, then narrow the policy to the smallest set of parameters and outputs needed. Capabilities that change records, move money, or access regulated data deserve stronger review than read-only tools. The decision should be based on the consequence of the action, not on the host application name.
Q: How do organisations govern agent access when one capability is shared across many hosts?
A: Governance has to sit on the capability itself, because the same tool may appear in a chat app, IDE, desktop client, or agent runtime. That means one entitlement model, one logging standard, and one confirmation policy per action, regardless of where the agent is running. Otherwise the same permission looks different in each surface.
Technical breakdown
MCP capability surfaces and agent discovery
MCP defines a shared interface for tools, resources, and prompts, so an agent can discover what a host exposes without a custom integration per model or client. That is materially different from a single-purpose API integration, because the same capability can be surfaced across IDEs, chat interfaces, desktops, and agent runtimes. The technical change is standardisation of discovery and invocation, which means governance must attach to the capability object itself rather than the host application alone. In practice, the security boundary moves from the transport to the published action.
Practical implication: inventory exposed MCP capabilities as governable assets, not just integration endpoints.
Confirmation gates and scoped actions for risky tools
MCP can require explicit confirmation for irreversible actions and can scope inputs with JSON Schemas, which makes the tool call itself the control point. This matters because the agent may be autonomous in deciding when to act, but the platform can still constrain what is reachable and what must be acknowledged before execution. The important distinction is that safety is enforced at the capability layer, not assumed from the surrounding chat or app context. That reduces the blast radius of dangerous actions such as deletes, refunds, or production changes.
Practical implication: wrap destructive agent actions in guarded tools with confirmation and tightly typed inputs.
MCP transport does not remove identity and authorisation requirements
MCP uses JSON-RPC over transports such as stdio and streamable HTTP, but the transport choice does not answer who is entitled to see or invoke a capability. The article’s governance point is that access should be role- and tenant-aware, with auditability attached to every tool call. In other words, transport standardisation improves portability, while authorisation still has to decide which user, tenant, or context may discover a capability at all. That separation matters for IAM teams designing policy around distributed agent surfaces.
Practical implication: enforce entitlement checks and audit logging above the transport layer, not inside it.
Threat narrative
Attacker objective: The objective is to turn standardised agent access into overbroad execution against data or workflows the user should not be able to reach.
- Entry occurs when an MCP-aware host discovers a published capability surface and the agent is allowed to enumerate tools, resources, or prompts.
- Escalation occurs if the agent can reach capabilities that exceed the user’s entitlement or can invoke risky actions without confirmation gates.
- Impact occurs when the agent executes destructive or sensitive operations through a standardised tool call with insufficient scoping, logging, or tenant isolation.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Capability surfaces, not connectors, are becoming the governance unit for agent access: MCP turns integrations into reusable published actions that can be discovered across hosts. That changes the control problem from engineering a one-off connection to governing what the agent may see, call, and confirm. IAM and NHI teams should treat published tools as inventory items with policy attached, not as incidental implementation details.
Tool discovery collapses the old assumption that integration equals entitlement: access was designed for systems where a connector existed only because a workflow had already been approved. That assumption weakens when an agent can discover a capability at runtime and decide to invoke it from a different host or model. The implication is that capability visibility, invocation rights, and confirmation requirements must be governed as separate decisions.
Least privilege now has to be expressed at the capability level: traditional role design can say who may use a product, but not always which agent-facing action is safe to expose. MCP forces the discussion down to discrete tools, parameters, and irreversible operations. Practitioners should expect policy to move from app-level access to action-level authorisation and tenant-aware discovery.
Guarded actions are more valuable than broad automation claims: the article is right to emphasise confirmations, schemas, and scoped outputs because agent autonomy only stays safe when the tool boundary is narrow. That is the operational lesson for the broader identity market: governance will increasingly be judged by what a capability can do without human intervention, not by how elegantly it is integrated.
New concept: capability discovery governance: MCP creates a governance problem where the first decision is not whether an agent may act, but whether it should even learn that an action exists. That concept matters because exposure, invocation, and execution are now separable events. Security teams should design policy around that sequence, not around integration presence alone.
From our research library:
- 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.
- Read next: AI Agent Identity Security Buyer's Guide
What this signals
Capability discovery governance: MCP makes exposure itself a governance event, because an agent can only be controlled properly when discovery, invocation, and confirmation are treated as separate policy decisions. That is where IAM teams need to concentrate their next controls, especially when the same tool surface is reused across multiple hosts.
As MCP spreads, the programme question shifts from whether an integration exists to whether the capability is entitled, logged, and constrained everywhere it appears. That is a better fit for identity governance than host-by-host exceptions, because the control follows the action rather than the application surface.
For practitioners
- Map published MCP capabilities Catalogue every exposed tool, resource, and prompt as a governed asset with an owner, sensitivity level, and entitlement boundary.
- Separate discovery from invocation rights Ensure an agent can only enumerate capabilities that the current user or tenant is entitled to see, and log both discovery and use.
- Require confirmations for irreversible actions Treat deletes, refunds, and production changes as guarded tools that require explicit acknowledgement before execution proceeds.
- Audit parameter scope and output limits Review JSON Schemas so the agent can only send narrowly typed inputs and receive only the minimum output needed for the task.
- Instrument every tool call Record who triggered the call, which capability was reached, and whether the action completed, so access reviews can be based on actual use.
Key takeaways
- MCP changes the unit of governance from a connector to a capability surface, which forces policy to follow the tool rather than the host.
- The most important controls are entitlement scoping, confirmation gates, and auditability for each discrete action.
- IAM and NHI teams should treat discovery, invocation, and execution as separate decisions when governing agent access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP still depends on strong authentication before capabilities are exposed or invoked. |
| NHI-05 — Overprivileged NHI | The article centres on scoping agent capabilities to the minimum entitlements needed. | |
| NHI-10 — Human Use of NHI | MCP can expose actions that require human confirmation before an agent executes them. | |
| Recommendation — Tie MCP access to strong authentication before any capability discovery or invocation is allowed. Scope every MCP tool to the minimum privilege required for the action it performs. Require human confirmation for high-impact MCP actions that would otherwise run under agent identity. | ||
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | The article focuses on agent tools and the risk of overbroad or unsafe invocation paths. |
| ASI03 — Identity & Privilege Abuse | MCP governance is about preventing agents from exceeding intended privilege boundaries. | |
| Recommendation — Constrain agent tool selection so only approved actions can be invoked in each workflow. Enforce least-privilege policy on agent identities and check privilege before each tool call. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Overbroad agent access can enable credential abuse and movement across connected systems. |
| Recommendation — Map risky MCP paths to credential access and lateral movement tactics for detection planning. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article repeatedly stresses entitlement scoping and role-aware listings for capabilities. |
| Recommendation — Use PR.AA-05 to govern which users and tenants may discover and invoke each MCP capability. | ||
| NIST Zero Trust (SP 800-207) | Least privilege — Least privilege | MCP aligns with zero-trust expectations that each action is explicitly authorised. |
| Recommendation — Apply least privilege to every MCP capability so discovery and execution are separately controlled. | ||
Key terms
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- Capability Surface: The set of actions, data objects, and prompts an agent can discover and invoke through a protocol such as MCP. It is not just a technical interface. It is an identity governance boundary that determines what an agent can see, call, and potentially repeat across environments.
- Guarded Tool: A tool that requires extra control before execution, such as human confirmation, input validation, or policy checks. Guarded tools are used for irreversible or high-impact actions, where the organisation wants the security gate attached to the action itself rather than to the front-end that initiates it.
- Discovery Governance: Discovery governance is the practice of controlling which capabilities an agent may learn about before it can invoke them. This matters because exposure itself can create risk, and in agentic environments the first security question is often whether a capability should be visible at all.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org