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.
Why default OpenAPI-to-MCP exposure is too broad
OpenAPI describes what an API can do, but an MCP tool catalogue describes what an autonomous client is allowed to do. Those are not the same trust decision. If you expose every operation by default, you are turning a documentation surface into an execution surface, including endpoints that may be destructive, admin-only, or unsuitable for unattended use.
That difference matters because tool availability changes the blast radius. A read-only endpoint can often be safe to expose, but write actions, bulk exports, destructive deletes, and privilege-bearing admin functions need a separate authorization decision before they become agent tools.
Teams also need to remember that many OpenAPI specs are intentionally complete, not intentionally safe. Security often fails when teams treat the spec as a permission model instead of a catalogue of capabilities that still needs classification, owner approval, and runtime constraint.
How to decide what gets exposed as a tool
The practical pattern is explicit allow-listing first, then risk-based expansion. Start with the operations that are clearly low risk, narrowly scoped, and easy to observe, then evaluate anything that changes state, moves data, or affects other users with much tighter controls.
For higher-risk tools, the key question is whether the action can be safely bounded at runtime. If the operation can trigger unintended side effects, cross-tenant access, workflow fan-out, or irreversible changes, it should not be exposed just because it exists in the OpenAPI document.
Good classification usually considers four things together: the sensitivity of the data touched, the scope of the action, the reversibility of the change, and the likelihood that an autonomous caller could misuse the endpoint under prompt injection, confused-deputy conditions, or simple operator error.
What mature MCP exposure looks like in practice
Mature teams treat tool exposure as a governed interface design problem. They keep the MCP layer narrower than the raw API surface, attach human review to high-impact actions, and use runtime policy to constrain when an agent can call sensitive tools, with what inputs, and under what context.
That is why guidance for agentic systems increasingly centers on tool misuse and identity abuse controls, not just API syntax. The OWASP Agentic AI Top 10 is useful here because it frames the problem as runtime authority, not just API inventory.
If you are working from MCP directly, the authorization model also matters. The MCP authorization specification is a reminder that servers should be treated as protected resources with constrained token handling, not as open pass-throughs for whatever the client can reach.
In practice, the safest exposure pattern is to publish only the tools the agent truly needs, keep destructive and administrative actions behind separate approval paths, and make policy decisions visible enough that teams can audit why a tool was available at all.
Risk and Threat Considerations
Auto-exposing every operation creates a broad attack and mistake surface. The main risk is not just accidental misuse, but also prompt-injected or maliciously influenced agents reaching endpoints that were never meant to be autonomous, then performing actions with legitimate credentials and high trust.
Failure mechanism: The MCP layer inherits the full API surface without separating low-risk read actions from high-impact write or admin actions, so a compromised or overconfident agent can invoke destructive endpoints, move sensitive data, or trigger privilege-bearing workflows.
Impact: That can lead to unintended deletions, mass data exposure, unauthorized changes, lateral movement through trusted integrations, and incidents that are hard to reverse because the actions were performed through valid interfaces rather than obvious abuse.
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 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | MCP tool exposure governs how agents invoke operations and can misuse tools. |
| ASI03 — Identity & Privilege Abuse | Auto-exposure can grant agents more authority than intended for autonomous use. | |
| ASI09 — Human-Agent Trust Exploitation | Overexposed tools can be abused when agents inherit misplaced trust in prompts or inputs. | |
| Recommendation — Limit tool exposure and gate high-impact actions before agents can invoke them. Constrain agent permissions and separate admin-capable actions from routine tools. Require approval and runtime checks for actions that rely on user-provided intent. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Exposed operations need function-level checks so agents cannot call admin actions by default. |
| API6 — Unrestricted Access to Sensitive Business Flows | Bulk export, approval, and destructive workflows should not be auto-exposed to agents. | |
| Recommendation — Enforce function-level authorization on every tool mapped from an API operation. Restrict sensitive flows and require explicit approval for high-impact operations. | ||
Practitioner Guidance
What to prioritise: Classify endpoints before you expose them. Read-only, idempotent, and narrowly scoped operations are the first candidates; bulk export, deletion, approval, and admin actions should be evaluated much more conservatively.
Decision rule: If a tool can change state outside the agent’s immediate task, require a separate approval or policy gate. If the action is reversible only with difficulty, treat it as high risk even when the API itself is authenticated.
What to verify: Confirm that the MCP catalogue is smaller than the raw OpenAPI spec by design, and that every exposed tool has an owner, a reason for exposure, and a clear failure mode if the agent tries to overreach.
Practitioner takeaway: The goal is not to expose everything the API can do, it is to expose only what autonomous use can do safely, with the rest held back by explicit policy and human accountability.