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.
Why This Matters for Security Teams
MCP changes the security problem from “can a client call an API?” to “can an autonomous agent safely discover, choose, and use tools at runtime?” That matters because agents are goal-driven: they do not follow a fixed user journey, and they can chain actions in ways REST-only reviews do not anticipate. Security teams that treat MCP as just another API layer often miss the policy and identity implications until the agent has already acted beyond scope, a pattern highlighted in AI Agents: The New Attack Surface report.
REST still needs classic controls such as authentication, RBAC, input validation, rate limiting, and logging. MCP adds a second layer where tool discovery, session state, and runtime authorization become the control plane for the agent itself. That is why current guidance from OWASP Agentic AI Top 10 and OWASP Agentic Applications Top 10 treats authorization failure, tool misuse, and over-permissioned agents as first-order risks, not edge cases.
In practice, many security teams encounter MCP risk only after an agent has already queried a sensitive tool or chained into a system it was never meant to reach.
How It Works in Practice
Think of REST as the service interface and MCP as the orchestration interface for the agent. REST endpoints expose business functions and data. MCP servers expose tools, schemas, prompts, and session context so an agent can discover what exists and decide what to invoke. For security teams, that means two different trust decisions: one at the API boundary and one at the agent boundary.
For REST, the standard playbook still applies: enforce Ultimate Guide to NHIs — What are Non-Human Identities principles, use strong workload identity, and map access to least privilege. For MCP, the question becomes whether the agent should be allowed to discover a tool at all, whether the tool should be visible only in a specific context, and whether the session should carry ephemeral authorization rather than long-lived secrets. That aligns with the direction described in Analysis of Claude Code Security, where agentic systems need tighter runtime governance than ordinary app clients.
- Use REST controls to protect the service: authn, authz, input controls, and audit trails.
- Use MCP controls to govern the agent: tool registry filtering, session scoping, and context-aware approvals.
- Prefer JIT credentials and short-lived secrets for tasks that an agent can complete autonomously.
- Evaluate policy at request time, not only at onboarding time, because agent intent changes during execution.
For frameworks, the control model is consistent with OWASP Top 10 for Agentic Applications 2026, CSA-MAESTRO, and NIST-AIRMF because all three assume runtime behavior must be bounded, observed, and revoked when it exceeds intent. These controls tend to break down when MCP tools are exposed through loosely governed internal platforms because discovery is easier than authorization and teams mistake visibility for trust.
Common Variations and Edge Cases
Tighter agent control often increases integration overhead, requiring organisations to balance safety against developer speed and operational complexity. There is no universal standard for MCP enforcement yet, so teams should treat current guidance as evolving rather than settled.
One common edge case is a mixed estate where REST services are well protected but MCP wrappers are added later without matching policy, identity, or logging. Another is when an agent uses a shared backend token to reach multiple tools, which defeats per-task scoping and makes blast radius larger than the underlying REST design suggests. The safer pattern is workload identity for the agent, JIT issuance for each task, and explicit intent-based authorization before tool use.
This is also where Ultimate Guide to NHIs — Why NHI Security Matters Now becomes relevant: the identity problem is not only “who called the API” but “what autonomous entity was allowed to act, for how long, and with what delegation.” Teams should align that model with CSA-MAESTRO and NIST-AIRMF, then validate it against the agentic risks catalogued in the OWASP Agentic AI Top 10.
These patterns break down in highly dynamic multi-agent workflows because tool choice, delegation, and privilege escalation can change between one step and the next.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agent tool misuse and overreach are central to MCP governance. |
| CSA MAESTRO | MAESTRO-3 | Covers runtime controls for autonomous agent behaviour and tool use. |
| NIST AI RMF | AI governance must account for dynamic autonomous behavior, not static access. |
Require session-scoped approvals and continuous policy checks before every agent tool invocation.
Related resources from NHI Mgmt Group
- How should security teams choose between CLI and MCP for AI tool access?
- How should security teams govern AI agents that can access enterprise systems?
- What is the difference between function calling and MCP for enterprise security?
- How should security teams choose AI security platforms for enterprise use?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
