iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
MCP can help a client discover tools and send a selected tool call to a server. Discovery and selection do not authorize that call. Before a consequential action runs, a host, gateway, or equivalent runtime needs to check whether this agent may use this tool with these arguments, in this session, and then allow, deny, or require approval.
What happens between selection and execution?
A typical MCP flow makes tools available to a model, lets the model choose one, then sends its proposed name and arguments to a server. OpenAI’s connector documentation describes this flow and an approval path in which a user can review the proposed tool and arguments before a call proceeds: OpenAI’s remote MCP guide.
The missing security step is a separate authorization decision at the runtime boundary, before the server performs the action. The model’s choice is a proposal—not proof that the action is permitted. Microsoft frames the gap as the interval between a model deciding to call a tool and the call being validated as permitted, properly scoped, and auditable. Its article recommends deterministic evaluation for each call, returning an explicit allow, deny, or approval outcome: Microsoft for Developers, April 22, 2026.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteA practical policy can consider the authenticated user and agent, server and tool identity, argument values, credential scope, resource sensitivity, side effects, and session policy. These are useful design dimensions, not a universal MCP policy schema; implementations must define their own rules.
#1 Best Overall
Why tool selection is not a security boundary
Tool definitions can influence the model
A tool’s name, description, and other metadata shape what the model believes it can do. A malicious or compromised server can use misleading definitions to steer selection or behavior. OWASP categorizes this risk as tool poisoning (MCP03). The MCP project has also said tool annotations are hints that clients should treat as untrusted by default; several proposed trust and sensitivity annotations discussed in March 2026 were drafts, not universally supported enforcement features: MCP project discussion.
Tool results can steer later calls
Returned content may include instructions that influence the model’s next decision. OWASP calls this contextual prompt injection (MCP06), and Microsoft describes how one tool’s output can propagate into an agent’s next action. A result must not silently authorize a subsequent sensitive call.
Arguments and credentials can exceed the user’s intent
Untrusted input used to construct commands, API calls, or code can create command-injection and unsafe-execution risks (OWASP MCP05). Weak authorization, excessive permissions, or shared context can expose data or permit actions beyond the user’s intent (MCP07 and MCP10).
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteUnapproved servers make the tool set less trustworthy
Unapproved, compromised, or lookalike servers can enter an environment, while missing telemetry makes incidents harder to investigate. OWASP includes software supply-chain attacks, shadow MCP servers, and inadequate audit and telemetry among its risk categories. These categories identify risks; they do not establish how often those risks occur.
What controls belong in a secure call path?
- Limit what can be selected. Register servers through an approved process, review their definitions, and expose only the tools the agent needs. OpenAI documents an
allowed_toolsoption and recommends preferring official provider-operated servers where available. Its guidance also warns that remote servers can contain hidden prompt injections or change behavior. Review what information will be sent to a server: OpenAI’s remote MCP guide. - Make a per-call policy decision outside the model. Evaluate the caller, server, tool, arguments, permissions, and action sensitivity in deterministic code or policy infrastructure. Return allow, deny, or require approval before execution. This is an architectural recommendation, not a feature guaranteed in every MCP client.
- Require meaningful approval for sensitive side effects. Show the actual tool and arguments in a review interface, and bind approval to that proposed call. OpenAI documents an approval-request flow that handles calls individually; a vague or blanket confirmation is not an adequate substitute for reviewing what will happen.
- Constrain credentials and data. Use least privilege and review which user or resource data leaves the host. Authentication can establish who is connected and what broad access exists, but it does not decide whether each proposed action is acceptable in context.
- Handle outputs as untrusted input. Inspect or constrain returned content, and keep instructions inside tool results from bypassing policy checks on later calls.
- Record decisions and outcomes. Keep enough information about calls, policy decisions, approvals, and relevant context changes to support auditing and incident response.
- Check version and cache scope. Match behavior to the protocol version actually deployed. Fresh tool lists help clients account for changes, but freshness is not authorization; check consequential calls when they execute.
How do the main control approaches differ?
| Approach | Where control happens | What it contributes | Important limitation |
|---|---|---|---|
| Model instruction alone | In the prompt or model context | Easy to add as behavioral guidance | It is not an independently enforced boundary. Microsoft reported a 26.67% policy violation rate in an internal evaluation of 60 prompts, so prompt-only instructions should not be treated as sufficient security. |
| Per-call human approval | Before an individual call proceeds | Lets a person review the proposed tool and arguments | It depends on a clear review interface and must apply to the actual sensitive call. |
| Host or gateway policy | At the runtime boundary before execution | Can centrally enforce deterministic allow, deny, or approval decisions and record them | Requires deliberate policy design and deployment; it is not inherent in every MCP integration. |
| Server-side authorization | At the server protecting its resources | Checks whether the caller has access to server resources | Access alone may not answer whether this particular action is acceptable in the user’s current context. |
Microsoft’s 26.67% figure is specific to its internal red-team evaluation: 45 adversarial and 15 valid prompts, mapped to the OWASP Agentic Top 10. It is not an estimate of MCP deployments’ breach rate or a universal failure rate. The supported conclusion is narrower: prompt-only instructions were insufficient in that evaluation.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What changed in the 2026 MCP specification?
The MCP project’s article about the July 28, 2026 specification release describes freshness and cache-scope metadata, including ttlMs and cacheScope, for tool-list and related responses. These can help clients decide when a cached list is stale and whether it can safely be shared. They do not replace authorization when a call is made.
The same release article describes authorization changes: clients validate the OAuth response iss parameter before redeeming a code, client credentials gain issuer binding, and Dynamic Client Registration is formally deprecated in favor of Client ID Metadata Documents while remaining available for backward compatibility. These details are version-specific; verify them against the protocol version your deployment implements: MCP specification release article, July 28, 2026.
Authentication and issuer validation help establish which identity or authorization server is involved. They do not, by themselves, settle whether a particular agent should perform a particular action with particular arguments.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
