Topic starter
25/06/2026 1:23 am
TL;DR: OpenAPI-to-MCP translation expands agent reach faster than most authorisation models can govern, according to PermitIO. Endpoint policy is what keeps generated tools tied to approval, intent, and audit instead of broad delegated access.
Editorial analysis by NHI Mgmt Group, based on content published by PermitIO: “OpenAPI-to-MCP Turns Every API Into an Agent Tool. The Missing Piece Is Endpoint-Level Policy”.
Key questions
Q: Why do endpoint filters and runtime policy solve different problems for MCP tools?
A: Endpoint filters decide what the agent can discover at build time, while runtime policy decides whether a specific call is allowed in the current context.
Q: What do security teams get wrong about MCP and tool governance?
A: They often review each integration in isolation and miss the combined permission path.
Q: What breaks when OpenAPI endpoints are exposed as MCP tools without endpoint policy?
A: The control that breaks is delegated authority.
Practitioner guidance
- Apply endpoint risk classification Classify generated tools by method and business effect before exposing them to agents, with read, create, and destructive actions placed in distinct trust bands.
- Require runtime policy checks Evaluate every tool call at execution time against delegator identity, target resource, intent, and approval status instead of relying on static exposure rules.
- Remove high-risk endpoints from default exposure Keep delete, revoke, export, and transfer operations out of the initial tool catalog unless a specific business case and governance path exist.
Bottom line: OpenAPI-to-MCP translation expands agent capability faster than most authorisation models can explain or control.
Glossary terms: Endpoint-Level Policy, Delegation authority, Tool Catalogue, Runtime Authorisation
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
25/06/2026 10:46 am
Endpoint-level policy, not API connectivity, is the governing unit that matters. OpenAPI-to-MCP translation turns interface description into agent execution, but execution still needs a decision boundary. The article shows why capability exposure is easy and delegated authority is hard, which is exactly where identity governance has to sit. Practitioners should stop treating tool publication as an access decision.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: Should teams expose every OpenAPI operation as an MCP tool by default?
A: No. Teams should start with explicit allow-listing and risk classification, then add runtime policy for higher-risk actions. Auto-exposure is attractive because it is fast, but it routinely pulls in admin, destructive, or data-moving endpoints that were never meant for autonomous use.
👉 Read our full editorial: OpenAPI-to-MCP gateways need endpoint-level policy to stay safe