What matters first
- Accept tokens intended for the MCP server and validate the relevant identity context.
- Authorize each sensitive tool action and downstream resource.
- Review discovery, outbound requests, and tool permissions as separate boundaries.
Inventory the capabilities and trust relationships
List servers, clients, tools, resources, user identities, and downstream systems. Describe the authority behind each capability: reading a document, changing a record, sending a message, or administering an account. Remove capabilities the actual product workflow does not need.
Review local and remote deployment models according to the transport and authorization mechanisms in use. The MCP security guidance addresses several trust-boundary risks, while OWASP’s excessive-agency model helps evaluate unnecessary functionality and permissions in the connected assistant.
References: [1] Model Context Protocol, [2] OWASP
Validate tokens and enforce authorization
The MCP security guidance explicitly prohibits accepting tokens that were not issued for the MCP server. Review token audience and issuer checks and how the authenticated user is mapped to application permissions. Do not treat a token intended for another downstream API as an interchangeable credential.
Authorize the particular tool action and resource using trusted context. A client that can call one read-only operation should not automatically gain write access or cross-tenant visibility. Check whether the server uses a shared privileged account that exceeds the user’s actual authority.
References: [1] Model Context Protocol, [3] IETF, [4] OWASP
Review discovery and outbound access
The specification’s security guidance discusses risks in fetching metadata and URLs influenced by a remote server. Review destination validation, redirects, network access, and the handling of authorization-server metadata according to the client and deployment you operate.
Inspect secret storage and the permissions of downstream integrations. A tool description is not a substitute for enforcing access where the operation executes. Keep privileged credentials out of model context, ordinary logs, and unrelated tools, and define who can approve changes to server configuration.
References: [1] Model Context Protocol, [5] OWASP, [6] OWASP
Test the action and approval boundary
Use controlled accounts to test intended calls, rejected resource access, incorrect token recipients, and consequential operations that need user review. Connect the approval to the actual action and arguments rather than a broad earlier request that could be interpreted differently later.
Log proposed and completed sensitive operations with enough context for investigation while limiting sensitive content. Repeat tests when adding tools, changing scopes, or connecting a new provider. A useful review explains the authority of the whole workflow, from user identity to downstream effect.
References: [2] OWASP, [7] OWASP, [1] Model Context Protocol
Your next steps
- List tool capabilities, identities, downstream credentials, and sensitive actions.
- Review token recipient validation and per-resource authorization.
- Check metadata fetching, egress, secret handling, and approval requirements.
- Book a scoped review of the MCP workflow and its connected application.
Questions teams ask
Does connecting through MCP automatically make a tool safe?
No. The server, client, and downstream application still need correct identity, permissions, validation, and operational controls.
Can a read-only assistant use an administrator integration account?
That can create unnecessary authority. Review the specific functions and downstream permissions needed for the intended workflow.
Sources and editorial notes
Public-source facts are cited above. The review questions and action plans are Cyphen’s guidance for applying those lessons to your own systems. Sources checked on .