Notifications
Clear all
Topic starter
25/06/2026 12:49 am
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.
NHIMG editorial — based on content published by Frontegg: Model Context Protocol changes how agent capabilities are governed
Questions worth separating out
Q: How should security teams govern MCP tools in agent-enabled products?
A: Treat each MCP tool as a policy object with its own scope, approval rules, and audit requirements.
Q: Why does MCP increase the governance burden for IAM and NHI teams?
A: Because one published capability can be reused across many hosts, models, and runtime surfaces.
Q: What breaks when MCP discovery is not scoped to entitlement?
A: Agents can enumerate actions they should never have seen, which exposes operational intent and creates a wider misuse surface even before execution begins.
Practitioner guidance
- Map MCP tools to entitlement scopes Inventory every exposed tool, resource, and prompt, then require role and tenant-aware scoping before discovery is permitted.
- Bind confirmations to irreversible actions Require explicit approval for refunds, deletes, production changes, and similar high-impact tasks, and enforce that gate in the tool definition rather than in one specific client interface.
- Audit capability use across hosts Log each tool call with identity, host, tenant, input class, and outcome so that the same capability can be traced across chat surfaces, IDEs, desktops, and agent runtimes.
What's in the full article
Frontegg's full article covers the operational detail this post intentionally leaves for the source:
- How MCP changes product architecture when one tool surface must serve many hosts and models
- Why JSON-RPC, stdio, and streamable HTTP matter for deployment choices and lifecycle planning
- How capability packaging affects monetisation, measurement, and SLA reporting for agent-enabled products
- What Frontegg means by role- and tenant-aware listings in real product environments
👉 Read Frontegg's analysis of how MCP changes agent capability governance →
MCP and agent capability governance: what IAM teams need to know?
Explore further
25/06/2026 9:50 am
Capability portability creates identity blast radius: Once one MCP tool can be consumed by many hosts, the control problem stops being integration-specific and becomes identity-specific. The same exposed action can appear in a chat app, an IDE, or an agent runtime, each with different assurance levels. That means blast radius is defined by capability reuse, not by the original product boundary, and practitioners need to treat tool exposure as a governed identity surface.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, 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, according to SailPoint.
A question worth separating out:
Q: What should organisations do before enabling MCP for production workflows?
A: Classify every tool by impact, define which actions require human confirmation, and verify that audit logs capture identity, host, tenant, and outcome. Then test whether the same control intent survives across every client that can consume the capability. If it does not, the governance model is incomplete.
👉 Read our full editorial: Model Context Protocol changes how agent capabilities are governed
