Notifications
Clear all
Topic starter
02/09/2026 1:29 pm
TL;DR: MCP is moving beyond tool calling toward a broader agent operating layer, with Tasks, MCP Apps, enterprise-managed authorization, and experimental Skills all pointing to longer-running work, richer interaction, and more structured enterprise deployment, according to Aembit research. The governance challenge is that protocol expansion does not remove identity risk; it concentrates it around agent access, authorization, and lifecycle control.
NHIMG editorial — based on content published by Aembit: Is MCP the Next Operating System? When the Model Context Protocol (MCP) launched, the value proposition was clear
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.
Questions worth separating out
Q: How should teams govern MCP when it starts carrying long-running agent work?
A: Treat long-running MCP work as a governed execution state, not a simple API call.
Q: Why does enterprise-managed authorization matter for MCP deployments?
A: It matters because agents do not behave like one-off user sessions.
Q: Where do MCP server deployments most often fail in practice?
A: They fail when tool permissions are too broad and credentials are embedded in configuration files or otherwise left without clear access scoping.
Practitioner guidance
- Map MCP primitives to identity controls Classify Tasks, Apps, Skills, and enterprise authorization as governed identity surfaces, then assign ownership for scoping, review, revocation, and audit trails across each one.
- Treat task handles as privileged execution state Set expiry rules, cancellation authority, and state-transfer logging for every long-running task so work cannot persist beyond the intended control boundary.
- Review server-rendered interfaces for trust leakage Assess MCP Apps for embedded actions, hidden assumptions, and user interaction paths that could bypass normal identity and approval checkpoints.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- The roadmap language behind Tasks, including retry behaviour, result expiry, and long-term state handling.
- How MCP Apps and server-rendered interfaces change the interaction model for agents in production.
- The experimental Skills work, including discovery, metadata, and composition considerations.
- The enterprise-managed authorization direction and why agent identity is becoming a first-class concern.
👉 Read Aembit's analysis of how MCP is evolving beyond tool calling →
MCP Tasks, Skills, and enterprise authorization: what changes now?
Explore further
02/09/2026 1:30 pm
MCP is becoming an identity layer before it becomes an operating layer. The article’s real significance is not that MCP can do more, but that it is beginning to carry enterprise access decisions, long-running work, and structured agent behaviour. That moves it out of the category of simple integration plumbing and into the category of governed non-human identity infrastructure. Practitioners should treat MCP design choices as identity architecture choices, not just developer ergonomics.
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, according to Astrix Security's research.
A question worth separating out:
Q: What is the difference between MCP Tasks and a normal API request?
A: A normal API request ends with the response, but an MCP Task can continue as a durable work object that the client can check, update, or cancel later. That makes Tasks operationally useful, but it also means the task lifecycle needs the same governance attention as a privileged session.
👉 Read our full editorial: MCP is evolving into an agent operating layer, not just tools
