Model Context Protocol: How AI Connects to Approved Tools and Data
Model Context Protocol (MCP): How AI Connects to Approved Tools and Data
Learn how MCP connects compatible AI applications to resources, prompts, and tools—and why authentication, authorization, consent, validation, and monitoring still belong to the host application.
Important clarification: MCP is an integration protocol, not an authentication system, authorization policy, or security guarantee. A compatible connection can still be unsafe if the host fails to validate identity, permissions, inputs, destinations, or side effects.
What is Model Context Protocol?
Model Context Protocol, or MCP, is an open protocol for connecting compatible AI applications to servers that expose resources, prompts, and tools. It gives an application a structured way to discover and use approved capabilities instead of building a different integration for every model and service.
The protocol describes how compatible components communicate. It does not decide whether a user should access a record, whether a tool call is safe, or whether a server is trustworthy. Those decisions remain the responsibility of the host application and the organization operating the system.
Always check the official MCP specification and the documentation for the exact client and server versions you use.
The three core MCP capabilities
| Capability | What it provides | Control to add |
|---|---|---|
| Resources | Application-controlled context such as documents, records, or data | Check freshness, scope, ownership, and disclosure permissions |
| Prompts | Reusable instructions or templates supplied by a server | Review them as untrusted input and apply host policy |
| Tools | Callable operations that may read data or change state | Authenticate, authorize, validate, limit, log, and approve risky actions |
How the MCP architecture works
- The user and host define the task. The application establishes what the user wants, which data may be used, and which actions are in scope.
- The host authenticates the connection. It identifies the user, tenant, environment, and approved server rather than trusting a model-generated identity.
- The client discovers capabilities. The compatible client learns which resources, prompts, and tools are available under the current policy.
- The host applies policy. It checks permissions, validates arguments, constrains destinations, and asks for confirmation where the action is consequential.
- The server performs the permitted operation. The application records the request, result, errors, timing, and relevant evidence while protecting secrets and unnecessary personal data.
Security: MCP does not replace authorization
MCP can standardize communication between compatible applications, but it does not replace authentication or authorization. The host application should identify the user, enforce ownership and tenant checks, restrict data sources, validate every argument, and prevent the model from becoming the only policy layer.
High-risk actions need human confirmation
Require an explicit human confirmation step before actions such as sending an external message, changing permissions, deleting data, publishing content, making a purchase, moving money, or modifying a production system. Approval should bind to the exact action and its material parameters.
If the recipient, destination, amount, content, or other material parameter changes after approval, invalidate the approval and create a new decision. A human checkpoint is not a substitute for access control; the application must still authenticate the actor and enforce least privilege.
Threats to test before production
| Threat | Example | Mitigation |
|---|---|---|
| Prompt injection | A document tells the model to ignore the host policy | Treat retrieved text and prompts as untrusted; enforce policy outside the model |
| Data exfiltration | A tool is asked to send private records to an unexpected destination | Allow-list destinations, minimize data, and require approval for disclosure |
| Confused deputy | A tool uses the host’s access for a user who lacks that permission | Bind authorization to the user, tenant, session, tool, parameters, and policy version |
| Malicious server | A server returns unsafe content or unexpected instructions | Review server identity, scope, version, trust boundary, and revocation path |
| Replay or duplicate action | A retried call sends the same message twice | Use idempotency keys, timeouts, deduplication, and visible outcomes |
Evaluation before production
Test ordinary requests, ambiguous requests, prompt-injection attempts, unauthorized users, cross-tenant access, malformed arguments, tool failures, timeouts, replayed requests, and destructive actions. Keep a baseline without MCP so you can compare whether the integration improves the task without adding unacceptable risk.
Useful measures include permission failures, unsafe-action rate, valid tool-call rate, data leakage, latency, cost, human-correction effort, recovery time, and the percentage of actions with complete audit evidence.
Practical implementation checklist
- Identify the user, tenant, session, client, and server for every sensitive request.
- Expose only the minimum resources, prompts, and tools required.
- Keep secrets outside prompts and model-visible text.
- Validate tool arguments, destinations, ranges, and ownership outside the model.
- Use timeouts, rate limits, cancellation, idempotency, and safe error handling.
- Require confirmation before consequential external or state-changing actions.
- Log relevant events while redacting secrets and unnecessary personal data.
- Maintain a revocation procedure and test the emergency stop path.
Frequently asked questions
Does MCP let every AI model access every tool?
No. Compatibility depends on the host, client, server, transport, configuration, permissions, and implementation. A discovered tool is not automatically available to every model or user.
Does a valid tool schema make a tool safe?
No. A schema describes inputs and outputs. Security requires authentication, authorization, validation, least privilege, monitoring, and safe handling of side effects.
Are MCP prompts trusted instructions?
Not automatically. Prompts supplied by a server should be reviewed and treated as untrusted content until the host has checked them against policy.
Can MCP be used for read-only systems?
Yes. Read-only resources can still expose sensitive information, so identity, scope, ownership, privacy, logging, and revocation remain important.
What is the safest way to start?
Begin with a small read-only resource, a limited user group, explicit logs, a baseline, and a clear rollback or revocation path. Add state-changing tools only after the controls have been tested.
Conclusion
MCP provides a useful structured boundary between compatible AI applications and approved resources, prompts, and tools. Its value comes from clear interfaces and reusable integrations, not from removing the need for security engineering.
Use MCP with least privilege, strong identity, external authorization, validated inputs, human consent for high-risk actions, complete audit evidence, and a tested revocation path. That approach makes integrations more understandable and safer for both developers and users.
Join the conversation