Why do OpenAPI derived MCP tools need careful governance before they are exposed to AI agents?

Because the conversion is only as good as the source specification and the control plane around it. Stale endpoints, weak schemas, missing operation IDs, and poor descriptions can produce tools that are hard for agents to select and easy to misuse. Governance matters because the gateway becomes the enforcement point for auth, logging, and scope control.

Why This Matters for Security Teams

OpenAPI to MCP conversion looks simple until the tools are placed in front of an autonomous agent. At that point, the specification stops being documentation and becomes an execution contract. If the source API is stale, the schema is loose, or operation names are ambiguous, the agent can select the wrong tool, chain actions in unexpected ways, or surface data the original owner never intended to expose. Guidance from the OWASP Agentic AI Top 10 and NHIMG’s AI Agents: The New Attack Surface report both point to the same operational truth: the risk is not only model behaviour, but the tool surface the model can reach.

NHIMG’s cited research shows 80% of organisations report agents have already acted beyond intended scope, while only 52% can track and audit the data those agents access. That gap matters even more when MCP tools are generated from OpenAPI definitions, because the gateway often becomes the last enforcement layer before an action is executed. In practice, many security teams discover that a “safe” API catalogue becomes a live privilege-escalation path only after an agent has already used it in production.

How It Works in Practice

Governance starts before publishing the MCP server, not after the agent is connected. The OpenAPI source should be treated as security-sensitive input: every operation needs clear intent, tight schemas, explicit authentication requirements, and descriptions that help both humans and machines distinguish read-only actions from state-changing ones. The gateway or broker should then enforce auth, scope, and logging at runtime, rather than assuming the agent will behave predictably.

Practitioners usually get the most value from a small set of controls:

• Curate the OpenAPI spec so deprecated, internal, and ambiguous endpoints are excluded.
• Require operation IDs, meaningful descriptions, and strict request/response schemas.
• Map each MCP tool to a least-privilege scope, not to the full API surface.
• Issue short-lived credentials or delegated tokens per session or per task.
• Log tool selection, arguments, policy decisions, and downstream API calls for auditability.

This is where MCP-specific research becomes practical. NHIMG’s The State of MCP Server Security 2025 reports that only 18% of MCP server deployments implement any form of access scoping for tool permissions, and 53% expose credentials through hard-coded values in configuration files. That combination is especially dangerous for agentic workflows, because a poorly scoped tool plus static secrets creates a direct path from prompt to privileged action. Current best practice is evolving toward policy-as-code checks at request time, aligned with NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modeling framework principles. These controls tend to break down when the OpenAPI source is owned by multiple teams and changes faster than the MCP publishing pipeline can validate and re-authorize it.

Common Variations and Edge Cases

Tighter tool governance often increases publishing overhead, requiring organisations to balance agent agility against change-control discipline. That tradeoff becomes visible in environments with many internal APIs, rapid release cycles, or legacy endpoints that cannot be cleanly described in OpenAPI without workarounds. In those cases, the safest answer is often to expose fewer tools, not broader ones.

There is no universal standard for how much semantic enrichment an MCP tool description should include, but current guidance suggests descriptions should be enough to reduce tool confusion without leaking implementation detail. Read-only tools still need governance, because agents can chain them into reconnaissance or data aggregation workflows. Write actions need even stricter review, especially where side effects are irreversible or cross-system. NHIMG’s OWASP NHI Top 10 and the vendor research on agent scope drift both support a conservative approach: treat every generated tool as production privilege, not as harmless metadata. The pattern is weakest when teams auto-publish every OpenAPI operation into MCP without human review, because one ambiguous endpoint can become the agent’s easiest route around intended controls.

Related resources from NHI Mgmt Group

• How should organizations approach the governance of AI agents?
• What governance controls should every enterprise put in place before deploying AI agents?
• What makes agentic AI an NHI governance issue?
• Why is NHI governance critical in the age of AI attacks?