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.
Why REST and MCP Solve Different Problems
REST and MCP are not competing replacements in most deployments. REST is a general-purpose application interface for existing systems, optimized for broad client compatibility, stable resources, and mature operational patterns. MCP is narrower and more agent-oriented: it standardizes how an AI agent discovers tools, negotiates context, and works with scoped permissions while it acts on a user or workflow.
That distinction matters because ai agents are not just another API client. They need bounded authority, clearer discovery, and a way to move from “what can I call?” to “what am I allowed to do right now?” In practice, REST often remains the execution surface, while MCP becomes the control and mediation layer for agentic access.
For teams deciding architecture, the useful question is not which protocol is better in the abstract, but which caller type each protocol serves best. Human-driven applications usually fit REST well. Agent-driven interactions usually need a protocol that can express identity, consent, and action scope more explicitly.
When Keeping Both Is the Safer Architecture
The strongest default for most organisations is to keep existing REST services and add MCP where agents need structured access. That lets you preserve stable service contracts for current applications while giving agents a purpose-built entry point. It also avoids forcing legacy systems to absorb agent-specific concerns such as tool discovery, session context, or per-action authorization.
MCP security guidance is most relevant when you are deciding how to expose backend capabilities to agents without turning every endpoint into an agent-facing interface. The same logic applies to the protocol layer itself: MCP authorization is designed around audience-bound access rather than blind token reuse.
Keeping both also reduces migration risk. Existing REST integrations, monitoring, rate limiting, and API lifecycle practices can continue to do their job, while MCP can be introduced for the subset of workflows that benefit from agent discovery and delegated action. That usually produces less churn than redesigning mature APIs to satisfy agent requirements they were never built to serve.
What Should Drive a Replace, Add, or Keep Decision
Replace REST only when the real problem is that the interface itself is no longer suitable for the consuming population. For most enterprises, that is rare. Add MCP when agents need to choose tools dynamically, operate with scoped authority, or work across multiple services through a consistent control plane. Keep REST as the system-of-record interface for conventional applications, service integrations, and external developers who already understand HTTP and resource semantics.
AI agent authorisation guidance is the practical lens here: agent-facing access should be task-scoped, permissioned per action, and capable of human approval where the workflow demands it. That is a better fit for MCP than for a broad REST surface that was not designed around delegated, temporary, or context-sensitive authority.
There is also a design constraint that many teams underestimate. If you replace REST too early, you may end up recreating REST-like behavior inside a new protocol without gaining any real security or operational benefit. If you add MCP on top of REST, you can separate stable execution from agent control and let each layer do one job well.
Risk and Threat Considerations
Hybrid API patterns create risk when teams assume the new agent layer is automatically safer than the old application layer. The main exposure is over-privileged or poorly scoped agent access, especially when an MCP server becomes a convenient gateway to multiple downstream systems. That can turn a single agent compromise or prompt-driven abuse into broad authorization failure.
Failure mechanism: An organisation exposes existing backend actions to agents without tightening scope, binding tokens to the intended audience, or separating read from write operations. An attacker or misbehaving agent then reuses that access to reach more systems than intended, or to perform actions that were never meant to be caller-agnostic.
Impact: The result can be unauthorized data access, destructive actions, or lateral movement across services that were previously insulated by separate application flows. In agentic environments, the blast radius often grows faster than the interface count.
Where the protocol boundary sits matters for attack surface. OWASP API Security Top 10 remains relevant for the REST side of the house, especially where broken authorization or excessive resource access can expose core systems. For the agent-facing side, the same concern shifts toward delegated authority and scoped tool use rather than generic endpoint exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI agents need scoped authority and per-action authorization when using MCP. |
| Recommendation — Restrict agent permissions per action and require approval for high-risk operations. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | REST endpoints exposed to agents still need function-level authorization checks. |
| API2 — Broken Authentication | MCP and REST both depend on strong caller authentication before authorization. | |
| Recommendation — Enforce function-level authorization on every backend action exposed through REST. Validate caller authentication before allowing either protocol to invoke protected actions. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Protocol choice should preserve least privilege for both human and agent callers. |
| IA-2 — Identification and Authentication (Organizational Users) | REST clients and agent operators still require strong user authentication around access decisions. | |
| Recommendation — Limit each caller to the minimum privileges needed for its workflow. Authenticate users before granting access to sensitive application or agent workflows. | ||
Practitioner Guidance
What to prioritise: Preserve REST for existing workloads and introduce MCP only where an agent genuinely needs discovery, scoped delegation, or controlled action selection. Do not redesign a stable application API just because an AI agent will consume it.
What to verify: Check that every agent-facing action has explicit authorization boundaries, audience-restricted tokens, and a clear separation between low-risk read operations and higher-risk write or transact operations. If you cannot explain who can do what, the protocol choice is premature.
Decision rule: If the caller is a traditional application or developer integration, keep REST. If the caller is an autonomous or semi-autonomous agent that needs tool discovery and per-action control, add MCP as the mediation layer.
Practitioner takeaway: The architectural goal is not to pick one protocol and retire the other, but to place each caller on the interface that best matches its authority, scope, and operational risk.
Related resources from NHI Mgmt Group
- Why do AI architectures become harder to govern as organisations add agents and MCP tools?
- When should organisations add continuous controls for AI agents?
- When should organisations add runtime controls for AI agents instead of relying on monitoring?
- Should organisations allow AI agents to call privileged MCP functions?