MCP and REST together: what AI agent APIs need

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: AI agents need MCP-style discovery and sessions, while REST remains the backend layer for conventional application integrations.

Why it matters: IAM and platform teams need to understand that agent-facing API design changes how identity, scope, and authorization are enforced for non-human actors, not just how requests are transported.

Context

REST was built for developer-written clients that already know the endpoint, parameters, and authentication model before the call is made. MCP addresses a different problem: an LLM-powered agent that must discover capabilities, select tools, and preserve context while it works through a task.

For identity governance, that shift matters because the control point moves from static integration code to runtime authorization and session management. The article frames MCP as a layer over existing APIs, which means teams are not choosing between protocols so much as deciding how non-human actors should be allowed to discover and invoke tools.

Key questions

Q: How should security teams handle tool discovery for AI agents in MCP environments?

A: Security teams should treat tool discovery as a privilege boundary, not a convenience layer. Limit the tools an agent can see, defer loading until a task requires it, and log which capabilities were exposed before execution. That reduces context overload and makes misselection easier to detect and investigate.

Q: Why do REST APIs become harder to govern when the client is an AI agent?

A: REST assumes a caller that already knows the endpoint and the sequence of calls it needs. An AI agent chooses actions at runtime, so the main risk is not transport but uncontrolled tool selection across a live session. That pushes security teams to manage discovery, scope, and authorization as runtime controls instead of relying on static integration design.

Q: What signals show that an API layer is not ready for agentic access?

A: If the interface depends on static docs, manual adapters, or human memory of which endpoint to call next, it is not ready for an agent that reasons dynamically. A second warning sign is when the authorization model only works at login and not at each tool invocation. Those conditions usually mean the API was built for deterministic callers, not for non-human actors.

Q: Should organisations keep REST, add MCP, or replace one with the other for AI agents?

A: Most organisations should keep REST for existing applications and add MCP as the agent-facing layer. REST remains the execution backend for traditional clients, while MCP adds discovery, session state, and scoped authorization for non-human consumers. The decision is not binary; it is about aligning each protocol with the type of caller that uses it.

Technical breakdown

Why REST is efficient but opaque to agents

REST is stateless by design, which makes it predictable for human-built software and efficient for caching, load balancing, and horizontal scale. But the same properties make it opaque to an AI agent: the client must already know the endpoint, expected parameters, and error handling patterns. OpenAPI helps humans and tooling, yet it remains a static contract. For an LLM that is deciding at runtime which operation to use, REST provides the business interface but not the discovery layer or the conversational state needed for multi-step work.

Practical implication: Keep REST as the execution layer, but do not rely on it alone when the consumer is an AI agent that must discover capabilities at runtime.

How MCP changes tool discovery and session state

MCP uses JSON-RPC to expose machine-readable catalogs through tools/list, resources/list, and prompts/list, then keeps a stateful session open so the agent can chain actions without rebuilding context after every call. That changes the integration model from developer-authored routing to runtime capability negotiation. The server can describe tools with schema, intent, and execution boundaries, which makes the interface legible to model-driven clients. In practice, MCP is not replacing business logic. It is making existing functions discoverable and usable by non-human consumers that reason over tools rather than hard-coded endpoints.

Practical implication: Design agent-facing interfaces around explicit capability catalogs and session continuity instead of assuming the client will carry context itself.

Why OAuth 2.1 matters for agent access to APIs

When an AI agent acts on behalf of a user, identity, consent, and scope cannot be left implicit. MCP’s authorization model depends on OAuth 2.1 so the server can verify which user authorized which action and whether the presented token carries the correct scope at invocation time. That is an identity boundary, not just a transport detail. It also means tool access can be narrower than the underlying API surface, which is essential when a single agent may touch multiple resources in one session. The control question shifts from whether the API is reachable to whether each action is explicitly authorised for the current actor and context.

Practical implication: Bind agent actions to scoped OAuth tokens and verify authorization at tool invocation, not only at initial connection.

NHI Mgmt Group analysis

Runtime discovery is a governance boundary, not just a protocol feature. The article shows that MCP gives agents the ability to discover tools at the moment of use, which changes who controls access and when. That means API governance can no longer assume the client is a fixed, pre-integrated application. Practitioners should treat capability discovery as part of the authorization model, not as a convenience layer.

Static integration assumptions break when the consumer decides at runtime. REST assumes the caller already knows what to invoke, while MCP assumes the agent may choose from a live catalog. That difference matters for identity security because permission design moves from code deployment time to session time. The practical implication is that policy must follow the actor through runtime tool selection, not just through endpoint exposure.

Scoped authorization becomes the real control plane for agentic access. The article’s OAuth 2.1 emphasis is a reminder that agent access should be expressed as narrow, verifiable authorization rather than broad API reach. For non-human actors, the question is not whether they can connect, but which actions they can perform in the current session and on whose behalf. Practitioners should align agent permissions to the smallest tool scope that still supports the workflow.

MCP does not replace API governance, it exposes where existing governance was human-centric. REST remains the backend execution path, but MCP adds a new interface layer for discovery, state, and action. That means legacy API controls may still be necessary while no longer being sufficient for agent use. Teams should re-evaluate whether their current API authorization, logging, and session boundaries were designed for software callers or for agents that make decisions dynamically.

Runtime capability catalog: the article effectively describes a live inventory of agent-usable actions, and that inventory becomes the new object of policy review. If a capability is discoverable in-session, it is governable in-session only if the authorization model is equally dynamic. The implication is clear: identity programmes need a runtime view of what non-human actors can reach, not just a pre-approved integration list.

From our research library:

• Gartner predicts that by the end of 2026, 40% of enterprise apps will feature task-specific AI agents.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Runtime discovery shifts the control point from integration code to authorization policy. Once an agent can ask what a service can do at the moment it connects, the old assumption that the caller is pre-wired to a fixed workflow no longer holds. That makes least privilege a session problem, not just a provisioning problem.

Agent-facing APIs need a distinct governance model from developer-facing APIs. REST remains the right abstraction for deterministic software, but AI agents need stateful sessions, scoped tokens, and live capability catalogs. Organisations that expose the same surface to both without separation will struggle to explain who can do what, when, and on whose behalf.

For practitioners

• Define agent-facing tool boundaries Separate developer APIs from agent-facing tools so each MCP capability has a narrow, outcome-oriented scope and a clear allowed action set.
• Require scoped OAuth 2.1 tokens Issue authorization tokens that are tied to the user, the session, and the exact tool scope needed for each invocation.
• Preserve session context for multi-step workflows Design MCP interactions so the agent can carry state across related actions without rebuilding context from scratch at each call.
• Keep REST as the execution backend Retain existing REST APIs for business logic and expose only the workflows an agent actually needs through the MCP layer.
• Review authorization at tool invocation Validate permissions when the agent calls a tool, not only when the connection is established, so access matches the current action.

Key takeaways

• MCP is best understood as an agent-facing layer over existing REST APIs, not as a replacement for them.
• The governance shift is from static integrations to runtime discovery, scoped authorization, and session-aware tool use.
• Teams that expose APIs to AI agents should separate developer workflows from non-human access paths and validate permissions at invocation time.

Key terms

• MCP: Model Context Protocol, an open way for AI agents to connect to tools and data sources. It improves interoperability, but it also introduces a shared integration layer that must be governed carefully because the protocol can widen access across many systems at once.
• Stateful Session: A connection in which prior steps, context, and selected tools remain available across a workflow. For agents, stateful sessions improve task completion, but they also make the session the real unit of control, audit, and containment.
• Scoped Authorization: Scoped authorization limits a system to the minimum permissions and data needed for a specific task. For AI workflows, it constrains what the agent can touch, reducing blast radius, improving governance, and making access easier to audit when the workflow operates in production.
• Runtime Discovery: The process by which an AI agent asks a server what capabilities exist before using them. Unlike static documentation, runtime discovery creates a moving target for security review because new tools can appear without code changes on the client side.

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 IAM programme, it is worth exploring.