Notifications
Clear all
Topic starter
06/06/2026 1:49 am
TL;DR: Building an MCP server around a REST API turns endpoints into tools, resources, and prompts that an LLM agent can invoke directly, with OAuth-based authentication and streamable HTTP transport, according to WorkOS. The security question is no longer whether the API is usable, but whether its exposed surface, tool descriptions, and auth boundaries are tight enough for NHI and agent governance.
NHIMG editorial — based on content published by WorkOS: Building an MCP server from a REST API
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Inventory agent-facing action scope Map each REST endpoint to one of three outcomes: tool, resource, or exclusion.
- 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.
- 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.
What's in the full article
WorkOS's full guide covers the operational detail this post intentionally leaves for the source:
- Complete Python code for eight tools, three resources, and two prompts in a working MCP server.
- Step-by-step AuthKit OAuth integration for remote MCP authentication and redirect handling.
- Concrete examples of FastMCP decorators, resource URI templates, and tool return shaping.
- Testing and troubleshooting patterns for Inspector runs, conversation tests, and proxy buffering issues.
👉 Read WorkOS's guide to building an MCP server from a REST API →
MCP servers from REST APIs: are your controls keeping up?
Explore further
06/06/2026 3:09 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Building an MCP server from a REST API: IAM risks and controls
