Notifications
Clear all
Topic starter
06/06/2026 11:32 am
TL;DR: REST still fits developer-written integrations, but AI agents need runtime discovery, stateful sessions, and scoped authorization, so MCP layers over existing APIs rather than replacing them, according to WorkOS. The governance issue is not protocol choice alone, but whether identity, context, and tool access are being governed for non-human actors that decide at runtime.
NHIMG editorial — based on content published by WorkOS: MCP vs. REST and the right way to connect AI agents to APIs
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- JSON-RPC request and response examples for tools/list, tools/call, resources/list, and prompts/list
- A practical architecture pattern showing how an MCP server wraps an existing REST API without rewriting backend logic
- OAuth 2.1 and dynamic client registration details for agent-facing authorisation
- Implementation guidance for choosing between REST-only, MCP-only, or layered deployments
👉 Read WorkOS's explanation of how MCP and REST fit together for AI agents →
MCP vs. REST for AI agents: where each protocol fits?
Explore further
06/06/2026 12:23 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP and REST together: what AI agent APIs need
