How should security teams govern OpenAPI-to-MCP tool exposure?

Why This Matters for Security Teams

OpenAPI-to-MCP conversion turns documentation into executable reach. That matters because the resulting tools are not just convenience wrappers; they become permissioned actions that an AI agent can invoke at runtime. If teams expose every generated endpoint by default, they recreate the same problem that has driven many NHI incidents: broad, persistent access without a clear business need. NHIMG’s Guide to the Secret Sprawl Challenge shows how quickly credentials and capabilities spread once automation is treated as harmless infrastructure.

The risk is sharper with MCP because tool exposure can combine data access, side effects, and privilege delegation in one control plane. That makes semantic classification essential. Read-only search and fetch operations may be acceptable under wider conditions, but export, transfer, write, revoke, and admin functions should be treated as privileged NHI actions. Current guidance suggests this is not a packaging problem, it is an authorization problem. The OWASP OWASP Top 10 for Agentic Applications 2026 and NIST Cybersecurity Framework 2.0 both reinforce the need to govern runtime exposure, not just build-time generation. In practice, many security teams encounter overexposed MCP tools only after an agent has already used them in an unintended workflow.

How It Works in Practice

Governance should start before a tool is published to MCP. Security teams need a control gate that reviews the source OpenAPI operation, tags it by semantic risk, and decides whether it is eligible for exposure at all. Read-only endpoints can usually be allowed with lighter controls, but any tool that can create, update, delete, export, transfer, approve, or revoke should require explicit approval and tighter runtime checks. The practical rule is simple: if the operation can change state or move data, it should not inherit the same trust as a lookup call.

At runtime, policy must evaluate the request in context. That means checking the caller, the requested resource, the action type, the tenant or environment, and the current business context before the MCP tool executes. The current best practice is evolving toward policy-as-code with request-time decisions rather than static allow rules. Teams often pair this with workload identity, short-lived tokens, and full decision logging so they can prove who asked for what and why. NHIMG’s 52 NHI Breaches Analysis and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs are useful references for how poor lifecycle control and weak scoping turn machine identities into durable attack paths.

A practical implementation pattern looks like this:

• Import OpenAPI definitions into an internal registry before MCP publication.
• Assign each operation a risk label such as read, modify, export, or privileged admin.
• Default deny every tool unless explicitly allow-listed for a known agent or workflow.
• Apply JIT authorization and short-lived secrets for higher-risk actions.
• Log the tool name, parameters, decision, and downstream effect for audit and forensics.

These controls tend to break down when developers auto-publish large API catalogs into MCP without a review step because the policy layer never has enough semantic context to distinguish safe retrieval from dangerous privilege escalation.

Common Variations and Edge Cases

Tighter tool governance often increases friction for developers and agents, so organisations have to balance speed against blast-radius reduction. That tradeoff is real, especially when a product team wants fast coverage across dozens of APIs. The safer approach is to start with a narrow allow-list and expand only after each tool has a known owner, a defined business purpose, and a tested rollback path.

There is no universal standard for MCP risk classification yet, so teams should treat their taxonomy as a living control, not a permanent policy. For example, a “read-only” endpoint may still be high risk if it can enumerate secrets, reveal customer records, or expose workflow metadata that helps an agent chain into more powerful calls. Likewise, an export action may be acceptable in one environment but prohibited in another due to residency or regulatory limits.

The most difficult cases are multi-tool agent workflows, where one low-risk call feeds the next until the agent reaches an unintended privileged action. That is why current guidance favors runtime policy, step-up approvals, and least-privilege scoping for every tool edge. For broader agentic context, NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now and the OWASP Agentic Applications Top 10 help frame why dynamic agent behaviour demands stronger controls than traditional integration security.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?
• How should security teams govern non-human identities that have persistent access?