Building an MCP server from a REST API: IAM risks and controls

At a glance

What this is: This is a hands-on guide to building an MCP server from a REST API, and its key finding is that most of the security and governance work happens in the mapping choices before code.

Why it matters: It matters because MCP exposes application capability to AI agents, so IAM teams must think about tool scope, transport, and authentication as identity decisions, not just API design.

👉 Read WorkOS's guide to building an MCP server from a REST API

Context

Model Context Protocol turns application capabilities into agent-consumable tools, resources, and prompts. That changes the governance problem from API access alone to who or what can invoke each action, under which identity, and with what downstream privilege.

For IAM and NHI teams, the critical issue is that an MCP server can collapse multiple REST endpoints into a smaller set of agent-facing actions. That can reduce friction, but it can also hide privilege concentration if tool design, OAuth scope design, and resource exposure are not aligned.

Key questions

Q: How should security teams govern MCP servers that wrap REST APIs?

A: Security teams should govern MCP servers as agent-facing identity surfaces, not as simple API adapters. The key controls are tool scoping, resource separation, token-based authentication, and clear usage guidance so the model cannot infer broader privilege than intended. If those controls are weak, the MCP layer can concentrate access in ways that are harder to audit than the original API.

Q: Why do MCP servers create new NHI governance concerns?

A: MCP servers create new NHI governance concerns because they expose application capability to non-human callers through tools and prompts that can be invoked at runtime. That shifts the question from who can reach an API to what an agent is allowed to decide and execute. The governance challenge is preventing the agent from inheriting broader privilege than the user or workflow intended.

Q: What breaks when too many REST endpoints are exposed as MCP tools?

A: When too many REST endpoints are exposed as MCP tools, the model gets a larger, less distinguishable action set and privilege becomes harder to reason about. Similar tools overlap, descriptions blur together, and the chance of unintended action selection rises. The result is not just clutter. It is an expanded agent-facing attack surface that is harder to review and govern.

Q: Who should own authentication for a remote MCP server?

A: The server owner should own authentication for a remote MCP server because the server becomes the control point for every agent action. That means bearer token validation, OAuth flow handling, and access scope decisions must be enforced server-side, not left to the client alone. Without that ownership, the deployment risks becoming a loosely governed proxy for backend privilege.

Technical breakdown

Tool design and endpoint exposure in MCP servers

In MCP, a tool is not just an API wrapper. It is an agent-facing action with its own description, parameter schema, and operational intent. The article shows the important design step is deciding which REST endpoints become tools, which are merged, and which are omitted entirely. That matters because the model does not see the backend endpoint map. It sees the tool surface you define, and it will use descriptions to decide when a tool applies. Poorly separated tools create ambiguity, while overly broad tools concentrate privilege into a single callable action.

Practical implication: treat every tool as an identity boundary and keep the callable surface narrower than the backend API.

Resources, prompts, and agent-readable data flow

Resources are read-only MCP objects addressed by URI, while prompts are user-selected workflows that prime the model for a task. The distinction matters because resources can be fetched on demand without turning every read into an action, and prompts can encode repeatable workflows without making them autonomous. In governance terms, this separates inspection from execution. If teams blur these primitives, they make it harder to reason about what the agent can merely read versus what it can trigger. That distinction becomes especially important when resources contain sensitive context that could steer later tool calls.

Practical implication: classify each exposed element as read, act, or guide before exposing it to an agent.

OAuth and transport choices change the security model

The article contrasts stdio with streamable HTTP and notes that streamable HTTP is the standard for remote deployment because it fits normal HTTP infrastructure and has a real authentication model. That is the governance breakpoint. Once MCP leaves the local subprocess pattern, the server becomes a networked identity surface that needs bearer-token verification, OAuth flow handling, and clear session boundaries. Authentication is no longer incidental plumbing. It becomes the control plane for every tool call the agent can make against the backend service.

Practical implication: use remote transport only with explicit token verification, scope control, and server-side auth handling.

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 server design is now an identity governance problem, not just an integration exercise. The article shows that the real work happens in choosing which endpoints become tools, which remain read-only resources, and which workflows get prompt access. That is a governance decision about callable privilege, not a coding convenience. For IAM and NHI programmes, the exposed MCP surface is the new control point, and tool design should be reviewed like any other privileged access model.

Tool descriptions are policy, because models use them to decide action. In a traditional API, a caller already knows the endpoint it wants. In MCP, the model relies on the tool description, parameter hints, and usage guidance to select an action at runtime. That means weak descriptions can create accidental overreach even when the backend is correctly implemented. Practitioners should treat descriptive text as part of the security boundary, because it shapes which actions the agent believes it is allowed to take.

Read versus act separation is the difference between usable agents and uncontrolled agents. The article’s use of resources for retrieval and tools for actions maps neatly to least-privilege thinking. Resources should expose only what an agent needs to inspect, while tools should be narrow and task-specific. If every read becomes a tool or every tool returns broad data, the system becomes harder to audit and easier to misuse. That separation is the named concept here: agent-readable surface area, the amount of application capability an agent can directly perceive and invoke.

OAuth-based MCP authentication pushes identity decisions back into the server owner’s hands. Once the server is remote, the operator must decide how tokens are issued, verified, and scoped, and those choices determine whether the agent acts as a bounded NHI or as a loosely controlled proxy. That should force teams to revisit their assumptions about shared service credentials, delegated access, and environment-specific trust. The implication is clear: MCP governance belongs in the same conversation as NHI lifecycle and access policy.

Testing needs to include model behaviour, not just protocol correctness. The article rightly separates unit tests, Inspector-based integration tests, and conversation tests with a real model. That is a useful reminder that secure identity design is not validated until the model chooses the right tool, respects the narrow schema, and handles empty or partial failures cleanly. For practitioners, the issue is not only whether the server runs, but whether the agent behaves within the intended privilege envelope.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 44% of organisations have implemented any policies to govern AI agents, despite 92% saying that governance is critical to enterprise security.
• That gap makes OWASP Agentic AI Top 10 the right forward lens for teams designing MCP surfaces and tool boundaries.

What this signals

Agent-readable surface area: MCP design decisions determine how much application capability an agent can perceive, select, and execute. Teams that treat tools, resources, and prompts as separate governance objects will have a cleaner path to least privilege than teams that expose everything through one broad callable layer.

With 80% of organisations already seeing AI agents act beyond intended scope, per AI Agents: The New Attack Surface report, the practical concern is not adoption speed but privilege discipline. MCP implementations should be reviewed against OWASP Agentic AI Top 10 where tool misuse and identity abuse intersect.

As MCP moves from local subprocess patterns to remote HTTP services, the server becomes part of the identity perimeter. That means access review, session boundary, and token scope decisions need to be documented in the same way teams document privileged service accounts and delegated workload access.

For practitioners

• Inventory agent-facing action scope Map each REST endpoint to one of three outcomes: tool, resource, or exclusion. Review the final surface for privilege concentration, especially where multiple backend endpoints collapse into one agent-callable action. The goal is to reduce the agent-facing blast radius before any deployment.
• Tighten tool descriptions as control text Write tool descriptions to separate similar actions clearly, define when to use each tool, and include parameter hints that prevent the model from guessing. Treat the description as part of the policy envelope, not as documentation prose.
• Verify remote MCP authentication and scope For streamable HTTP deployments, require explicit bearer-token validation and align OAuth handling with the server’s intended privilege scope. Remote transport should never be treated as a simple connectivity choice because it turns the server into a network-exposed identity surface.
• Test the agent, not only the endpoint Run conversation tests with a real model after unit and integration testing. Confirm that the model selects the intended tool, respects structured outputs, and recovers cleanly from empty results or partial failures.

Key takeaways

• MCP server design is an identity control problem because tool mapping determines the agent-facing privilege envelope.
• Resources, prompts, and tools are not interchangeable, and confusing them increases both audit complexity and misuse risk.
• Remote MCP deployments need server-side authentication, explicit scope control, and real model-behaviour testing before production use.

Key terms

• Model Context Protocol: Model Context Protocol is an interface standard that lets AI agents discover and use tools, resources, and prompts exposed by a server. In practice, it turns application capability into agent-readable actions and read-only data, which makes scope design and authentication part of the identity problem.
• Tool: A tool is an MCP-exposed action that the model can choose to call at runtime. It is the equivalent of an executable privilege boundary, because its name, description, and schema influence what the agent believes it may do and what backend actions it can trigger.
• Resource: A resource is a read-only MCP object identified by a URI and fetched when the model needs supporting context. Resources are useful for exposing data without granting action rights, but they still carry governance implications if the data can influence later tool selection or reveal sensitive state.
• Prompt: A prompt is a user-invoked workflow template that primes an agent for a specific task sequence. Unlike tools, prompts are not autonomously called by the model, so they sit closer to guided orchestration than execution privilege, which makes them useful for repeatable, controlled workflows.

Deepen your knowledge

MCP server design and agent-facing privilege boundaries are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are mapping REST APIs into agent-consumable surfaces, the course is a strong fit.

This post draws on content published by WorkOS: Building an MCP server from a REST API. Read the original.