MCP and REST together: what AI agent APIs need

At a glance

What this is: This is a protocol comparison showing that REST remains the backend workhorse while MCP adds the AI-native discovery and session layer agents need.

Why it matters: It matters because IAM and API teams now have to govern non-human access that discovers tools at runtime, carries state across steps, and needs scoped authorisation.

👉 Read WorkOS's explanation of how MCP and REST fit together for AI agents

Context

MCP vs. REST is really an identity and governance question for AI agent consumers. REST was designed for deterministic software clients, while MCP was built for LLM-powered agents that need runtime discovery, session continuity, and tool invocation without custom integration code written in advance.

For IAM and security teams, the issue is that the consumer is no longer just an application calling an endpoint. The protocol stack now has to express who or what is acting, what it may discover, and how scoped authorisation follows the session across multiple steps.

technical_h3s:[{"heading":"Runtime tool discovery changes the trust model","body":"MCP replaces static, developer-read documentation with live protocol discovery. A client can ask a server what tools, resources, and prompts exist through tools/list, then call them through JSON-RPC methods such as tools/call. That means capability knowledge is no longer fixed at deploy time, and the agent can adapt as the server changes. The security implication is that the trust boundary moves from the API documentation layer to the runtime session layer, where discovery itself becomes part of the access decision.","practical_implication":"Practical implication: treat capability discovery as a governed action, not a harmless read step."},{"heading":"Stateful sessions create agent context that REST does not provide","body":"REST is stateless, so each request stands alone and context must be carried manually. MCP sessions persist, which lets an agent keep track of prior steps, chosen tools, and intermediate results while completing a workflow. That is efficient for multi-step automation, but it also creates a governance dependency: the session becomes the unit of control, audit, and failure analysis, not the single request. Identity teams need to understand that context persistence can extend both usefulness and blast radius.","practical_implication":"Practical implication: align logging, session scope, and revocation to the full agent workflow, not just one API call."},{"heading":"OAuth 2.1 scopes make authorisation visible to the agent layer","body":"The article frames MCP as compatible with OAuth 2.1, using scoped tokens and dynamic registration so the server can verify which actions a given client is authorised to perform. That matters because AI agents need fine-grained permissions that are evaluated at tool invocation time, not just at initial sign-in. In practice, this is how the protocol ties user consent, resource scope, and tool execution together without forcing the agent to infer permissions from documentation alone.","practical_implication":"Practical implication: model agent permissions as scoped runtime access, then validate every tool call against that scope."}

Key questions

Q: How should security teams govern AI agent access to APIs that use MCP?

A: Security teams should treat MCP-connected agents as governed non-human identities and enforce scope, session, and tool-level controls together. The right model is not endpoint-only authorisation. It is runtime discovery, scoped token validation, and full workflow logging so each agent action can be traced back to an approved session and purpose.

Q: Why do REST APIs alone fall short for AI agents?

A: REST APIs are stateless and developer-oriented, so they assume the client already knows what to call and how to chain requests. AI agents need live discovery, persistent context, and a uniform way to invoke tools across services. Without that layer, every integration becomes custom glue code with weak governance visibility.

Q: How do scoped tokens help when AI agents use external tools?

A: Scoped tokens let the server verify that an agent is authorised for a specific resource or action at the time of invocation. That reduces overbroad access, but it only works if the organisation maps scopes to real tool outcomes and records the session for audit. Scopes without telemetry are not enough.

Q: What is the difference between MCP and REST for enterprise security teams?

A: REST is the backend transport for business logic and data access, while MCP is the agent-facing protocol that adds runtime discovery and session management. Security teams need both layers because each solves a different problem. REST protects the service surface, while MCP governs how AI agents find and use that surface.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

MCP turns API consumption into governed runtime access, not just integration plumbing. REST remains the right abstraction for human-written code, but MCP adds a discovery and session layer that changes how non-human actors find and use functionality. That shifts the security question from endpoint exposure to runtime capability exposure, which is a materially different governance problem. Practitioners should treat the protocol boundary as an access boundary, not a convenience layer.

Session persistence is the named concept practitioners should watch: runtime context persistence. MCP sessions preserve state across multi-step workflows, so the agent does not need to rebuild context at each call. That improves task completion, but it also means the meaningful security object is the whole session, not the isolated request. Access review, audit, and containment models built around stateless requests will miss the real decision surface.

Scoped OAuth is necessary, but it does not remove the need for tool-level governance. The article shows that MCP can ride on OAuth 2.1 and token scoping, which is the right direction for authorising agent actions. But scope alone does not describe intent, sequence, or downstream impact when an agent chains multiple tools in one session. Practitioners should assume that authorisation is only part of the control story, not the whole answer.

REST and MCP are complementary layers, which is why governance must be layered too. The backend API handles business logic and data access, while MCP handles how agents discover and invoke that logic. That means policy, telemetry, and offboarding decisions need to exist at both layers or the organisation ends up with hidden control gaps. Identity teams should map which controls belong to the API, which belong to the MCP server, and which belong to the agent identity itself.

AI agent access is becoming a distinct NHI pattern rather than a variant of developer integration. Once an agent can discover tools at runtime, keep state, and act through scoped tokens, it behaves more like a governed non-human identity than a conventional API client. That changes entitlement design, review cadence, and blast-radius thinking across NHI and human IAM programmes. Practitioners should stop treating AI agent connectivity as a pure developer-experience problem.

From our research:

• 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 AI Agents: The New Attack Surface report.
• That same research found 80% of organisations report their AI agents have already performed actions beyond their intended scope, including unauthorised system access and sensitive data sharing.
• For the broader control model, see OWASP Agentic Applications Top 10 for the runtime risks that emerge when tool use is not tightly governed.

What this signals

Runtime context persistence: MCP sessions make the session itself the unit of governance, which is exactly where many IAM programmes are weakest. If your controls still assume isolated requests, you will miss the sequence that actually matters when an agent chains discovery, invocation, and follow-up actions across one conversation.

With only 52% of organisations able to track and audit what AI agents access, the governance gap is already visible in practice. That means agent inventory, session logging, and token scope review need to move ahead of broader rollout, not follow it.

Teams that already align API governance with NIST AI Risk Management Framework and agent-specific controls are better placed to separate safe runtime discovery from uncontrolled tool sprawl. The next step is to decide which agent actions belong in MCP, which belong in the backend API, and which should never be exposed at all.

For practitioners

• Separate REST business logic from MCP access policy Keep existing REST endpoints for application traffic, but enforce agent-specific discovery, scope checks, and logging at the MCP layer so runtime capability use is visible and reviewable.
• Define session-level audit requirements for agent workflows Record the full sequence of tools/list, tools/call, and resource access events so investigators can reconstruct how an agent moved through a workflow, not just that a request succeeded.
• Bind OAuth scopes to tool outcomes, not just sign-in Issue scoped tokens that are checked at each tool invocation and mapped to the actual side effect or read action the agent is attempting.
• Classify AI agents as governed non-human identities Place MCP-connected agents into NHI inventory, recertification, and offboarding processes so access does not outlive the workflow or session that justified it.

Key takeaways

• MCP changes AI agent integration from static API use to runtime discovery and session-based tool access.
• REST still matters, but it governs the service backend, while MCP governs how non-human actors find and invoke capabilities.
• IAM teams need scoped tokens, session logging, and NHI classification for AI agents before runtime access becomes operational debt.

Key terms

• Model Context Protocol: A protocol that lets AI applications discover tools, resources, and prompts from external servers at runtime and invoke them through a common interface. In governance terms, it moves access decisions into the live session and makes tool exposure part of the security boundary.
• 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.
• 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 Token: An access token limited to specific actions or resources. For AI agents, scoped tokens are useful only when the scope is checked at invocation time and tied to the actual side effect the tool can produce.

Deepen your knowledge

MCP and API governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are adapting identity controls for AI agents that discover tools at runtime, it is worth exploring.

This post draws on content published by WorkOS: MCP vs. REST and the right way to connect AI agents to APIs. Read the original.