Yes. Discovery should tell the assistant what exists, but it should not imply permission to use it. Separating the two reduces accidental privilege expansion and makes it easier to enforce review, approval, and revocation around the actions that actually matter.
Why separating MCP discovery from execution matters
MCP discovery should answer a narrow question: what tools, resources, and capabilities are available? Execution is a separate question: which of those actions is this caller actually allowed to perform right now? Keeping them distinct prevents tool catalogs from becoming an implicit permission grant and forces the runtime to make an explicit authorization decision before any side effect occurs.
This distinction matters because MCP environments often sit next to agents, APIs, and sensitive back-end systems. If discovery and execution are collapsed, an assistant can infer more authority than the operator intended, especially when the tool list includes administrative or high-impact actions. Clear separation also makes review, approval, and revocation much easier to reason about because access is attached to use, not to mere visibility.
For teams designing agentic integrations, the right mental model is “read the menu, do not order from it by default.” Discovery can be broad for usability, but execution should still be bounded by policy, user consent, scoped credentials, and server-side checks. That pattern aligns with the MCP authorization model, which treats the server as the enforcement point rather than assuming the client’s view of available tools is enough to authorize use.
What breaks when discovery becomes permission
When discovery doubles as authorization, the most common failure is accidental privilege expansion. A tool becomes “known” to the assistant and is then treated as effectively usable, even if it was only meant to be displayed, inspected, or considered for later approval. That creates a confused-deputy style risk: the assistant can act with more authority than the human operator realised was in scope.
The same pattern also weakens revocation. If access is inferred from the discovery layer, teams may have to remove tools from lists, configs, and caches just to stop execution, which is slower and error-prone. A cleaner design lets discovery remain stable while execution rights can be changed immediately, independently, and with better auditability.
In practice, the issue is not only overexposure. Separation also helps prevent unsafe defaults from spreading across environments. A tool that is safe in a development sandbox may be unacceptable in production, and a discovery-only interface makes that boundary easier to preserve than a single merged “available tools” view.
The strongest control principle here is least privilege with explicit gatekeeping. The MCP authorization specification reinforces that tokens and audience boundaries belong at execution time, while OWASP Agentic AI Top 10 treats identity and privilege abuse, plus tool misuse, as core agent risks. OWASP Non-Human Identity Top 10 similarly highlights how excessive privilege and long-lived access material can turn a useful integration into an easy abuse path.
How practitioners should design the boundary
The safest design is to treat discovery as informational metadata and execution as a separately authorized transaction. Tool listings should be readable enough for routing and planning, but they should not carry implied consent to invoke anything sensitive. That usually means the client can enumerate tools, while the server, gateway, or policy layer decides whether a given caller can invoke a given tool with a given scope.
What to verify: Check that every tool with side effects requires a distinct execution decision, not just inclusion in a registry or schema. Validate that the authorization check is performed at invocation time and that the decision includes the caller, the target tool, the requested scope, and the current environment.
Implementation sequence: First publish discovery metadata with no privileged defaults. Then bind execution to short-lived, scoped credentials or an approval step. Finally, log the invocation separately so review and revocation operate on actual actions rather than on the existence of tools.
Common mistake: Teams often harden the tool server but leave the discovery surface too broad, then assume the assistant will “do the right thing.” That fails as soon as a tool list becomes a prompt input, a cached capability set, or a routing hint that overstates what the caller may do.
Practitioner takeaway: If a tool can change state, touch data, or trigger an external action, discovery should inform the planner while execution should remain the only place where authority is actually granted.
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 Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP tool discovery can overstate agent authority and enable privilege misuse. |
| ASI02 — Tool Misuse | Discovery without execution gating can let agents call tools unsafely. | |
| Recommendation — Separate tool listing from invocation controls to prevent implied privilege. Gate every tool call with explicit authorization and scope checks. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Discovery-only exposure can turn non-human access into excess privilege. |
| NHI-07 — Long-Lived Secrets | Execution should not depend on broadly reusable credentials exposed by discovery. | |
| Recommendation — Constrain tool access to the minimum rights needed for each execution. Use short-lived, scoped credentials for tool execution and revoke quickly. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Separating discovery from execution enforces minimal access at use time. |
| Recommendation — Limit tool execution permissions to the minimum necessary scope. | ||
Related resources from NHI Mgmt Group
- How should teams govern AI agents that use MCP?
- When should organizations consider adopting advanced tool discovery for AI agents?
- How should security teams handle tool discovery for AI agents in MCP environments?
- How should security teams implement a centralized MCP gateway so tool discovery stays manageable across many servers and agents?
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