The control that breaks is delegated authority. The agent can see and chain callable operations, but the organisation has not defined which principal may use them, for what intent, or with what approval. That creates broad reach without corresponding decision rights, which is a governance failure, not just a technical one.
Why OpenAPI-to-MCP Exposure Breaks Authority Boundaries
When an OpenAPI surface is exposed as MCP tools, the important shift is not just technical discoverability, it is that callable API operations become agent-usable capabilities. Without endpoint policy, there is no explicit decision layer to constrain who may invoke which operation, under what conditions, or with what intent, so the toolset inherits broad reach without defined authority boundaries.
That is why the failure is governance first. The organisation may still have authentication somewhere in the stack, but the exposure pattern no longer expresses per-endpoint permissioning, approval context, or operation-level scope. The result is an authority gap that is easy for agents to exploit and hard for owners to audit after the fact.
What endpoint policy is supposed to decide
Endpoint policy turns a generic API surface into a controlled action surface. It should determine which principal can call each operation, whether the operation is read-only or state-changing, whether additional approval is required, and whether the call is acceptable in the current workflow or tenant context. In MCP terms, that is the difference between simply publishing tools and governing delegated use of those tools.
This is especially important because an OpenAPI description often lists many endpoints that are individually safe only when used by the right actor, for the right purpose, and with the right constraints. Exposing them as tools without that policy collapses the distinction between published capability and permitted action. The agent can then chain operations in ways the original API design did not intend as a single delegated workflow.
For MCP-specific authorisation patterns, see Model Context Protocol: Authorization specification, which frames MCP servers as OAuth 2.1 resource servers and keeps tokens bound to the right audience.
OpenAPI surfaces that become agent tools also need a clear view of operation-level abuse patterns, including broken authorisation and unrestricted access to sensitive flows. OWASP’s guidance on API Security Top 10 is directly relevant because the same control gap can appear once API functions are exposed as callable tools.
Why this becomes risky in agentic workflows
The main operational risk is not just “too many tools”, it is delegated action without constrained decision rights. An agent that can call a create, update, delete, or retrieval endpoint can often combine them into a workflow that exceeds the human user’s actual intent. That can lead to overbroad data access, unintended state changes, or cross-system actions that were never individually approved.
Once tools are chainable, the blast radius is shaped by the weakest endpoint in the set. A read endpoint may be harmless alone, but a read plus modify pair can enable discovery followed by action. In practice, this is why endpoint policy has to be evaluated at the operation level, not just at the API or application level.
The pattern is familiar in agent security research: tool use becomes dangerous when privilege is implicit and policy is missing. NHIMG’s OWASP Agentic Applications Top 10 and MCP Security Guide both reinforce that tool exposure and authorisation are separate design questions, not one control inherited from the presence of an API.
Risk and Threat Considerations
Exposing endpoints as MCP tools without policy creates a direct privilege-escalation path: the agent can access operations that the organisation never explicitly scoped to the current principal or use case. That expands the impact of prompt injection, tool misuse, or accidental overreach because the system has no robust boundary to stop valid-but-inappropriate calls.
Failure mechanism: The endpoint catalog becomes an implicit authorisation layer, so any tool that is technically callable is treated as acceptable to use. That breaks delegated authority by removing intent checks, per-operation approval, and scope limits from the control plane.
Impact: Attackers or misdirected agents can chain API actions, access sensitive data, or trigger destructive side effects with a level of legitimacy that is hard to distinguish from normal tool use. In a mixed human-agent environment, that can turn one exposed interface into many hidden abuse paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Tool exposure without policy enables agent privilege overreach. |
| Recommendation — Restrict tool access by principal, scope, and approval context before exposing endpoints. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Exposed endpoints need operation-level authorisation to prevent misuse. |
| Recommendation — Enforce function-level authorisation for every exposed operation. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Endpoint policy should limit callable operations to minimum required authority. |
| Recommendation — Limit each principal to the minimum endpoint permissions needed. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Tool invocation should be continuously evaluated rather than trusted by exposure alone. |
| Recommendation — Apply continuous verification to every tool invocation and decision path. | ||
Practitioner Guidance
What to verify: Check whether each exposed endpoint has an explicit policy decision behind it, not just authentication at the transport layer. If the answer is “the agent can call it because it is in the schema”, that is not a control, it is a disclosure mechanism.
Decision rule: If an operation can change state, reveal sensitive data, or trigger downstream side effects, treat it as requiring operation-level authorisation and scope review before exposing it as a tool. Read-only is not automatically low risk when the output can be chained into a more powerful action.
Practitioner takeaway: The key design question is not whether the endpoint is exposed, but whether delegated use of that endpoint is separately and explicitly bounded. If authority is not expressed at the tool layer, the agent will inherit a capability set that is larger than the organisation has actually approved.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org