MCP is evolving into an agent operating layer, not just tools

At a glance

What this is: MCP is shifting from a function-calling protocol toward an agent operating layer with Tasks, interactive apps, enterprise authorization, and emerging skills distribution.

Why it matters: IAM and NHI teams need to treat MCP as a governance surface, because access decisions, task state, and operational context are becoming part of the protocol itself.

Context

MCP, or Model Context Protocol, began as a standard way for language models to call external functions. The article argues that its newer extensions are pushing it into a broader operating layer for agents, where workflow, state, and authorization matter as much as the tools themselves.

That matters because the governance problem is no longer limited to whether an agent can invoke a tool. Once Tasks, interactive apps, and enterprise-managed authorization are in scope, identity, approval, and operating context become part of the control plane that IAM and NHI programmes have to govern.

Aembit frames this as a shift from isolated tool access toward coordinated agent operation across enterprise systems. For practitioners, the key question is how to govern access and execution when the protocol now carries both request handling and operational state.

Key questions

Q: How should security teams govern MCP in enterprise environments?

A: Treat MCP as an identity and authorization problem first. Assign ownership for every agent and tool, enforce runtime policy checks on each invocation, and limit what context can flow between tools. The goal is to reduce the agent’s blast radius before it reaches downstream systems, not to rely on static perimeter controls after the fact.

Q: Why does enterprise-managed authorization matter for MCP deployments?

A: It matters because agents do not behave like one-off user sessions. If an organization wants agents to access systems under defined conditions, then central policy, auditability, and revocation must apply to the agent identity itself. Without that, MCP becomes another path to broad, poorly governed non-human access.

Q: What breaks when MCP access is built without lifecycle controls?

A: Access becomes difficult to track, review, and remove, especially when client registration is dynamic or token issuance is delegated to another system. The failure is not only technical. It is governance drift, where active clients and scopes no longer match current business need. That creates lingering access paths and weak accountability.

Q: How can teams evaluate whether MCP Apps create extra trust risk?

A: Teams should ask whether server-rendered interfaces can influence approvals, data entry, or workflow choices beyond the original tool response. If they can, the trust boundary has expanded and the interaction surface needs the same scrutiny as the underlying API or identity path.

Technical breakdown

Tasks turn MCP into long-running work orchestration

Tasks are an official MCP extension that lets a server return a task handle instead of forcing a single request-response cycle to stay open. That changes MCP from a synchronous tool-calling pattern into a stateful workflow primitive, where the client can poll, update, or cancel work after the initial call. The architecture matters because it introduces durable task state, retry semantics, and lifecycle questions that are closer to workflow orchestration than simple API invocation. Once work can outlive the original request, identity and authorization decisions must remain valid across the task lifecycle, not just at invocation time.

Practical implication: govern task issuance, task cancellation, and state expiry as part of the identity model, not just the application workflow.

MCP Apps add interactive UI to agent execution

MCP Apps let servers provide interactive HTML interfaces that hosts can render alongside tool interactions, including forms, buttons, and other interface elements. Technically, that pushes MCP beyond machine-readable outputs into server-supplied interaction surfaces that can guide, constrain, or request additional input from the user or host. This reduces parsing ambiguity, but it also expands the trust boundary because the server now influences not only data returned to the agent but also how the user interacts with the workflow. In identity terms, the protocol starts blending application UX, authorization, and execution context.

Practical implication: review which server-rendered interactions can change decisions, approvals, or data exposure before they are allowed into production.

Enterprise-managed authorization changes who owns agent access

Enterprise-managed authorization shifts MCP away from per-user, per-server authorization toward centrally governed identity and access decisions. Instead of every agent interaction inheriting a user-centric access model, the organization can bind the agent to an enterprise identity and define access conditions centrally. That is a material change for governance because it creates a clearer control point for audit, entitlement review, and policy enforcement. It also makes MCP closer to an identity integration layer than a loose tool gateway, especially when combined with future roadmap work on agent identity and security.

Practical implication: map agent identities to enterprise authorization policy now, before ad hoc per-user authorization becomes the default operating model.

Threat narrative

Attacker objective: The attacker or rogue workflow seeks durable, governed-looking access that can continue operating across tasks, interfaces, and enterprise systems.

1. Entry begins when an agent receives access through MCP tools, Tasks, or server-rendered interfaces that extend beyond a single call.
2. Credential or authorization abuse can follow if enterprise-managed authorization is weak, stale, or tied to the wrong identity boundary.
3. Escalation occurs when long-running task state or reusable procedures allow the agent to continue operating after the original decision point.
4. Impact is broader operational reach across enterprise systems, with access, execution, and auditability all becoming harder to separate.

Breaches seen in the wild

• Twitter source code leak 2023: Twitter source code and internal tools were posted to GitHub by "FreeSpeechEnthusiast" and stayed public for months before a 2023 takedown.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Tasks, Apps, and enterprise authorization turn MCP into a governance surface, not just a transport. The article shows that protocol evolution is concentrating identity decisions inside the interaction layer itself. That means access, state, and user interaction are no longer separate design concerns. Practitioners should treat MCP as part of the identity control plane, not just an integration channel.

The old assumption that an agent only needs momentary tool access is no longer sufficient. Long-running Tasks create state that persists beyond a single request, and that persistence is where governance pressure increases. The implication is that entitlements, approvals, and cancellation rights need to be understood as lifecycle controls for machine work, not only as one-time permissions.

Enterprise-managed authorization is the most important governance signal in the article because it moves MCP toward centrally owned access policy. That shift aligns with NHI governance principles, where identities must be inventoried, scoped, and revoked as operational actors rather than treated as anonymous callers. The practical conclusion is that central policy becomes more valuable than per-integration exceptions.

Protocol-native identity is emerging as a distinct concept for MCP. When the protocol itself starts carrying identity, workflow, and interaction primitives, the security model has to move upstream into issuance and authorisation time. That is a structural change for NHI governance because the protocol is no longer just consuming identity services. Practitioners should plan for governance to be embedded in the agent runtime, not bolted on after deployment.

Skills will matter only if organisations can govern reusable agent procedure, not just the tool surface. The proposal described in the article points toward packaged operational behaviour with prerequisites, side effects, and retry logic. That is useful only when it can be inventoried, constrained, and reviewed like any other high-risk non-human capability. The practitioner takeaway is to prepare for procedure-level governance, not just tool-level approval.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Protocol-native identity will become the deciding governance issue for MCP. Once the protocol carries long-running tasks, interactive surfaces, and enterprise authorization, identity can no longer sit outside the workflow. Teams should expect MCP governance to converge with NHI lifecycle thinking, because the execution model now depends on persistent, reviewable access boundaries. The shift is less about a new protocol feature set and more about where control must be enforced.

Skills and Tasks together point to procedure-level governance. The article’s direction suggests that future MCP deployments will need to govern reusable procedures, not just callable functions. That changes how teams think about inventory, review, and offboarding for machine capabilities. In practice, the question becomes whether your controls can see and constrain operational behavior, not just individual endpoints.

For practitioners

• Map MCP to an identity control plane Classify MCP integrations by the identities, entitlements, and approval points they introduce, then decide which enterprise controls own each boundary.
• Treat Tasks as lifecycle-scoped work units Define when a task may start, pause, resume, expire, or be cancelled so that long-running agent work does not outlive its authorization context.
• Review server-rendered interfaces before production use Assess whether MCP Apps can influence user decisions, approvals, or data handling in ways that expand the trust boundary beyond the tool response.
• Build policy for reusable skills before adoption Inventory any skill-like procedures by prerequisites, side effects, and escalation paths so they can be governed as reusable operational capabilities.

Key takeaways

• MCP is no longer best understood as a simple tool-calling layer, because Tasks, Apps, and enterprise authorization move it into identity-sensitive agent operations.
• The main governance challenge is the collapse of the old boundary between integration and control, where workflow state and authorization become part of the protocol.
• Practitioners should prepare for task lifecycle governance, central authorization, and procedure-level oversight before MCP use expands further.

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.
• Task handle: A task handle is the durable reference returned for a long-running MCP execution. It lets a client poll status, request results, or cancel the work later. In identity terms, the handle is a capability, so it must be scoped to the same actor and context that created it.
• Enterprise-Managed Authorization: Enterprise-managed authorization is a policy model in which the identity provider decides what an agent may do and encodes that decision into the token or access flow. It helps organisations keep control logic centralized instead of spreading entitlement decisions across many servers.
• Server-Rendered Interaction Surface: A user interface provided by a server and rendered by the host so an agent or user can interact with buttons, forms, or other controls. In MCP, this expands the trust boundary because the server can shape decisions and workflow steps, not just return data.

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.