This guide is narrower than a general connection review. If you are approving a packaged connector — an account, its scopes, whether content is indexed and how it is revoked — work through how to evaluate connector permissions instead. Come here when the thing being connected is a specific MCP server, because you are also taking on the software or operator behind it. For where MCP sits relative to APIs and agent-to-agent protocols, see MCP, APIs, A2A and native connectors compared.
Where the trust boundary actually sits
MCP standardizes how an AI client discovers and calls tools. It is a protocol, not a trust guarantee: the client trusts whatever server you connect, so selecting and reviewing that server is your responsibility, not the protocol's.
Stage 1
You and your content
Your prompt, plus any document, ticket, email or web page the assistant reads. Some of that content is written by people outside your organization.
Stage 2
AI host or client
ChatGPT, Claude, Gemini or a desktop client. It decides which tools to surface, when to ask for confirmation, and what it sends onward.
Stage 3
MCP server
The new boundary. It publishes the tool list, receives the model's tool calls and holds or brokers the credentials used against the backing system.
Stage 4
Backing application and data
The CRM, repository, mailbox, file store or internal service that actually changes when a tool runs.
The protocol’s own guidance is explicit that clients trust the servers they are connected to, which makes server selection a human decision. Read it in the MCP security best practices (opens in a new tab) and the specification (opens in a new tab).
Local versus remote MCP servers
Neither model is inherently safer. They fail differently, so they need different review questions. A local server is installed software; a remote server is an operator relationship.
| Review dimension | Local / stdio server | Remote / HTTP server |
|---|---|---|
| What you are trusting | A program or package running on the machine, usually with the signed-in user's privileges. | An operator who runs the endpoint, holds or brokers tokens and can see what passes through it. |
| First thing to inspect | The exact command, arguments and package version the client will run — a one-click install should reveal it and ask for explicit consent. | The server URL, its TLS certificate, who owns the domain, and the OAuth scopes it requests. |
| Blast radius | Filesystem and network reach of the user account, unless you sandbox or restrict it. | Whatever the granted scopes reach in the backing service, from anywhere the operator runs. |
| Supply chain | Package registry, dependencies, build and update mechanism. Pin versions where you can. | The operator's own deployment pipeline and subprocessors, which you cannot inspect directly. |
| Data handling question | What leaves the machine, and to which endpoints does the server itself call out? | What is retained, where it is stored, for how long, and under whose terms? |
| Change control | You control upgrades — which also means nothing patches unless someone owns it. | The operator can change tools and behavior without asking you, so you need change detection. |
| Evidence you can get | Host telemetry, process and network monitoring, local client logs. | Client-side invocation logs plus whatever server-side audit trail the operator offers. |
For local servers, the guidance is to treat the server like installed software: a one-click install or config should reveal the exact command it will run and require explicit consent, and filesystem and network privileges should be restricted or sandboxed where possible. Source: Model Context Protocol (opens in a new tab)
15 checks before you connect
Five groups, fifteen checks. Each one names what to inspect, why it matters, and a question that can only be answered yes or no — so a review produces a decision rather than a feeling.
A. Who built and operates it?
Almost every later question depends on this one. An MCP client trusts the servers it is connected to, and server selection is a decision made by the user or administrator — not something the protocol validates for you.
Check 01
Confirm the publisher and the official distribution point
- Verify
- Find the named organization or maintainer behind the server, and reach it from a link the vendor itself publishes rather than a search result, screenshot or chat message.
- Why it matters
- If you cannot attribute the server to a real operator, you cannot meaningfully review its software, updates, credentials, data handling or revocation path.Source: Model Context Protocol (opens in a new tab)
- Pass or fail
- Can you name the legal entity or maintainer responsible, and did you reach the server through their own documentation?
Check 02
Check release provenance and pin a version
- Verify
- For a package or container, note the registry, the exact version or digest, the repository it builds from, and whether releases are signed. For a hosted server, note the domain owner and certificate.
- Why it matters
- Supply-chain substitution and silent updates are documented MCP risks, especially for local packages and servers whose tool definitions can change after approval.Source: OWASP GenAI Security Project (opens in a new tab)
- Pass or fail
- Do you know exactly which artifact or endpoint you are approving, by version or digest?
Check 03
Decide whether it runs locally or remotely, and who controls that runtime
- Verify
- Establish whether the server is a local process on a user machine or a hosted endpoint, and which team or company owns the runtime, patching and monitoring.
- Why it matters
- A local MCP server is installed software with the user's privileges; official guidance is to treat it like any other program you install, with sandboxing and restricted filesystem and network access where possible.Source: Model Context Protocol (opens in a new tab)
- Pass or fail
- Is there a named owner for the runtime, and does your review match the hosting model?
C. How do authentication and data flow work?
MCP authorization builds on OAuth 2.1 security practice. You do not need to implement it, but you do need to ask the questions that reveal whether the operator did.
Check 08
Check the token model: audience binding, no passthrough
- Verify
- Ask whether tokens are issued specifically for this server, whether the server validates that it is the intended audience, and whether it refuses tokens it was not issued. Confirm tokens are never forwarded onward as-is.
- Why it matters
- The specification requires servers to reject tokens not issued for them and forbids token passthrough; the July 2026 revision hardened issuer validation further and moved away from dynamic client registration toward client metadata documents.Source: Model Context Protocol (opens in a new tab), Model Context Protocol (opens in a new tab)
- Pass or fail
- Can the operator state plainly that tokens are audience-bound to this server and never passed through to upstream APIs?
Check 09
Map where prompts, inputs and results are processed and stored
- Verify
- Establish which components see prompt text, tool arguments, retrieved records and results; then read the operator's retention, residency and subprocessor terms.
- Why it matters
- Tool traffic can carry sensitive prompt text, arguments, retrieved records and results, so its data path needs explicit review.Source: Google (opens in a new tab)
- Pass or fail
- Can you draw the data path and name every party that sees content along it?
Check 10
Confirm credentials are not exposed, and know how to rotate them
- Verify
- Check that secrets do not appear in URLs, tool results, error messages or logs, and record how credentials are stored, rotated and revoked.
- Why it matters
- Secure token storage and a tested revocation path limit how long compromised credentials remain usable.Source: Model Context Protocol (opens in a new tab)
- Pass or fail
- Do you know today how to rotate and revoke every credential this server holds?
D. Can untrusted content change model behavior?
The model reads tool descriptions and tool output as text. Anything written by someone else can try to influence what it does next.
Check 11
Read the tool names, descriptions and schemas as untrusted input
- Verify
- Review the manifest wording itself for instructions aimed at the model — text telling it to ignore rules, call another tool, or attach extra data.
- Why it matters
- This is tool poisoning: the description is part of the model's context, so a hostile description is an injection vector. Official guidance is to treat descriptions, annotations and results cautiously unless the server is trusted.Source: Model Context Protocol (opens in a new tab), OWASP GenAI Security Project (opens in a new tab)
- Pass or fail
- Have you read the actual manifest text, not just the marketing page?
Check 12
Plan for tool drift and “rug pulls”
- Verify
- Find out whether the client shows a diff when tool definitions change, whether you can pin a version, and what event forces a re-review.
- Why it matters
- An approved server can change its tools later. Without change detection, your approval covers a manifest that no longer exists.Source: OWASP GenAI Security Project (opens in a new tab), OpenAI (opens in a new tab)
- Pass or fail
- Would you find out this week if this server added or rewrote a tool?
Check 13
For local servers, inspect the start command and restrict host privileges
- Verify
- Read the exact command, arguments, environment variables and dependencies, then run it with the least filesystem and network access it needs — a container, a restricted user, or an explicit allowlist.
- Why it matters
- A one-click local install should reveal the command it will run and require explicit consent; sandboxing and privilege restriction are recommended in the protocol's own security guidance.Source: Model Context Protocol (opens in a new tab)
- Pass or fail
- Could this process read or send anything on the machine beyond what the use case needs?
E. What happens when it acts?
Approval design and traceability are what make a write-capable server operable rather than merely permitted.
Check 14
Keep human approval on destructive and high-impact actions
- Verify
- Confirm which actions prompt for confirmation, keep confirmation on anything irreversible, and hold back blanket “always allow” until a specific tool is proven and narrowly scoped.
- Why it matters
- Anthropic advises reserving “allow always” for tools you trust to run unsupervised, and OpenAI documents confirmation prompts before important write actions with some especially risky actions blocked. Confirmation reduces harm; it does not prevent a convincing malicious instruction from being approved by a distracted person.Source: Anthropic (opens in a new tab), OpenAI (opens in a new tab)
- Pass or fail
- Is every irreversible action still gated by a human decision?
Check 15
Require logs, an owner, a kill switch and a review cadence
- Verify
- Confirm you can see which tool ran, on whose behalf, when, and with what safe parameters; name an owner; document the disconnect and credential-revocation path; and set a re-review date.
- Why it matters
- Invocation logging and clear revocation are what let you answer questions after the fact instead of guessing.Source: OWASP Cheat Sheet Series (opens in a new tab)
- Pass or fail
- If this server misbehaved, could you prove what it did and revoke access promptly?
The Connector Scout decision rubric
Our framework, not a vendor standard
Do not connect
Any one of these is enough on its own. Stop and go back to the publisher.
- The publisher or operator cannot be identified from first-party sources.
- Broad credentials are requested with no explanation tied to a use case.
- The server can run shell commands or reach arbitrary filesystem paths with no sandbox.
- There is no documented way to disconnect it and revoke its credentials.
- Where prompts, tool inputs and results are stored, and under whose terms, is unclear.
- The tool manifest materially exceeds the job you are approving it for.
Pilot only
Trustworthy enough to test on a disposable tenant with a named owner and an end date — not to roll out.
- A credible publisher, but broad write or delete tools in the manifest.
- A new or beta server with no track record and no published change history.
- Weak change control: no tool diff, no version pinning, no notification path.
- Logs exist but do not clearly attribute an action to a person.
- Usable functionality effectively requires a blanket “always allow”.
Approve for scoped use
All of these hold, and the approval names the scope it covers.
- Named publisher, named internal owner, documented runtime.
- Narrow credentials on the narrowest resource that works, rotated on a schedule.
- The tool manifest has been read, classified by effect, and unused tools disabled.
- The data path is known and the operator's retention terms are acceptable.
- Approval gates remain on destructive and high-impact actions.
- Tool changes are detected, and a re-review date is on the calendar.
- Disconnect and credential revocation have been tested, not assumed.
What each platform does and does not do for you
The three AI hosts divide the work differently. None of them reviews every custom MCP server you can connect, and the differences decide how much of this checklist you have to carry yourself.
| Safeguard | ChatGPT | Claude | Gemini Spark |
|---|---|---|---|
| Who must vet a custom MCP server | Your organization. OpenAI states that unsafe or untrusted MCP servers increase exposure to risks including prompt injection, and that organizations are responsible for vetting custom or third-party MCP apps before publishing them.Source: OpenAI (opens in a new tab) | You. Anthropic notes custom remote connectors may connect to services Anthropic has not verified, and advises connecting only servers you trust.Source: Anthropic (opens in a new tab) | You. Google states plainly that it does not control, monitor or secure third-party MCP servers, and that supervising and trusting the provider is your responsibility.Source: Google (opens in a new tab) |
| Registry versus custom | Apps in the OpenAI-approved registry have gone through review. A custom app you upload yourself is not automatically OpenAI-verified.Source: OpenAI (opens in a new tab) | A custom remote MCP connector you add by URL may point to a service Anthropic has not verified.Source: Anthropic (opens in a new tab) | Custom apps are added by MCP server URL, subject to the eligibility requirements Google states for Gemini Spark.Source: Google (opens in a new tab) |
| Write and action confirmation | ChatGPT may ask for confirmation before important write or modify actions, and some especially risky actions may be blocked.Source: OpenAI (opens in a new tab) | Claude asks for approval and lets you disable tools you do not need; “allow always” is documented as appropriate only where the tool is trusted to run unsupervised.Source: Anthropic (opens in a new tab) | Manual confirmation is currently required for write actions in Gemini Spark custom apps.Source: Google (opens in a new tab) |
| Change control after approval | When a connected MCP server changes, updates are not enabled automatically. Admins can refresh, review changed actions as a diff, and new actions arrive disabled by default.Source: OpenAI (opens in a new tab) | Anthropic advises monitoring for changes in tool behavior and reviewing approval requests rather than accepting them by habit.Source: Anthropic (opens in a new tab) | Google advises reviewing the provider's privacy policy and terms, and monitoring and removing apps you no longer need.Source: Google (opens in a new tab) |
| Automation and research caveat | Deep research can use custom apps for read and fetch only, not write.Source: OpenAI (opens in a new tab) | Claude Research can invoke connector tools automatically and may make many requests; Anthropic recommends disabling write-action tools while using it.Source: Anthropic (opens in a new tab) | Gemini may draw on the current chat and other available context such as connected apps and personal intelligence, so an over-permissioned custom app can receive more than the task needs.Source: Google (opens in a new tab) |
| Local and private servers | ChatGPT connects to remote MCP servers directly; private, on-premises or local servers use the Secure MCP Tunnel where it is supported. Full MCP including write is in beta for Business, Enterprise and Edu on the web, while Pro can connect MCP servers with read and fetch permissions — confirm current eligibility before planning a rollout.Source: OpenAI (opens in a new tab) | Remote connectors are brokered from Anthropic's cloud infrastructure; local MCP servers configured in Claude Desktop are a separate mechanism that runs on the machine.Source: Anthropic (opens in a new tab) | Custom apps connect by MCP server URL, so the server must be reachable by Google's service under the eligibility Google documents.Source: Google (opens in a new tab) |
Custom-app support in the Gemini column is the Gemini Spark surface Google documents, not the ordinary Gemini app or Gemini Enterprise. Platform behavior and eligibility change often, so confirm against ChatGPT connector documentation, Claude connector documentation and Gemini connector documentation before you plan a rollout.
A seven-step pilot test
Sandbox only
Step 1
Connect with a low-privilege test account
Use an account whose data you are willing to lose, in a tenant with nothing sensitive in it. Record the scopes you granted.
Step 2
List the tools and compare against the expected manifest
Ask the assistant to enumerate the tools it now has from this server, and diff that list against what the vendor documented. Unexpected entries are a finding, not a curiosity.
Step 3
Run a read request and probe the boundary
Retrieve something you expect to be in scope, then ask for something that should be out of scope. The out-of-scope request should fail cleanly.
Step 4
Trigger a harmless write, then deny it
Create a throwaway record and confirm the approval prompt appears and describes the action accurately. Then deny an identical request and verify nothing changed on the backing system.
Step 5
Place untrusted instructions in test content
Put a line of adversarial text in a disposable test document — for example an instruction to email a file elsewhere — and watch whether the model attempts an unintended tool call. Do this only in the sandbox, with no real credentials or real recipients.
Step 6
Read the logs and test change review
Confirm the log names the tool, the actor, the timestamp and safe parameters, with no secrets in it. If the platform offers a refresh-and-diff review of changed tools, exercise it once so you know what it looks like.
Step 7
Disconnect, revoke, and verify access stops
Remove the connection and revoke the credential, then attempt a previously working call. Assume nothing about revocation until a request actually fails.
Once a server passes, the next question is what to do with it. The 15 practical AI connector workflows mark where approval belongs in each pattern, and the AI connector compatibility matrix often shows a documented first-party connection already exists, which is usually less work to govern than a custom server.
Questions to ask a vendor
Send these before approval, and keep the answers with the approval record. A vendor who cannot answer the credential and logging questions has told you something useful.
- Publisher and hosting
- Which legal entity operates the server, in which regions does it run, and is a self-hosted deployment supported?
- Tools and scopes
- What is the complete current tool manifest, which tools write or delete, and what is the minimum scope set for a read-only deployment?
- Credentials
- How are tokens issued, bound to this server, stored, rotated and revoked, and are they ever forwarded to upstream services unchanged?
- Data retention
- What prompt, argument and result data is retained, for how long, where, and is it used for training or product analytics?
- Subprocessors
- Which third parties process our data through this server, and how are we notified of changes?
- Tool updates
- How are tool additions and description changes communicated, can we pin a version, and is a changelog published?
- Security disclosure
- Where do we report a vulnerability, what is your disclosure policy, and have there been incidents affecting this server?
- Audit logs
- What server-side log can we obtain, how is an action attributed to an individual user, and how long is it retained?
- Revocation
- What is the documented path to terminate access immediately, and how is deletion confirmed?
- Patching and support
- What is your patch cadence for the server and its dependencies, and what support commitment applies to security fixes?
The Model Context Protocol project publishes its own security policy and coordinated disclosure process, which is a reasonable benchmark to hold a vendor's answer against. Source: Model Context Protocol (opens in a new tab)
What the protocol does not solve for you
- “It speaks MCP, so it is safe.” MCP standardizes the interface between a client and a server. It says nothing about whether the operator is trustworthy or competent.
- “It uses OAuth, so permissions are minimal.” OAuth governs how authority is delegated, not how much. A correctly implemented flow can still hand over a tenant-wide scope.
- “The user has to confirm, so nothing bad can happen.” Confirmation is a meaningful control and it reduces harm, but a convincing instruction hidden in retrieved content can still produce an approved action. Treat it as a brake, not a barrier.
- “We self-host, so our data never leaves our infrastructure.” Self-hosting controls where the server runs. If a cloud assistant is the client, prompts and tool results still travel to that AI host, so the data path includes it.
- “It is in a registry, so someone reviewed it for us.” Registry or directory review is useful evidence and worth weighting. It is not organization-specific: nobody in that process knows which data your account can reach.
Who governs the bridge is the underlying decision, and it is covered in in-product connectors versus MCP servers. How we source, date and re-check every claim on this site is set out in our verification methodology, and dataset changes are listed in the verification changelog.
Frequently asked questions
Research basis
Each claim above links to its source where the claim is made. The full list is repeated here for auditing: the Model Context Protocol’s own security and authorization material, first-party ChatGPT, Claude and Gemini documentation, and independent OWASP guidance used as secondary reference rather than vendor requirement.
- Official documentationModel Context Protocol
MCP security best practices (2026-07-28) (opens in a new tab)
Accessed 9 Sept 2026
- Official documentationModel Context Protocol
MCP authorization: security considerations (2026-07-28) (opens in a new tab)
Accessed 9 Sept 2026
- Official announcementModel Context Protocol
Model Context Protocol specification release, 28 July 2026 (opens in a new tab)
Accessed 9 Sept 2026
- Official documentationModel Context Protocol
MCP specification (2025-11-25) (opens in a new tab)
Accessed 9 Sept 2026
- Official documentationModel Context Protocol
MCP specification: authorization (opens in a new tab)
Accessed 17 Aug 2026
- Official documentationModel Context Protocol
Model Context Protocol security policy (opens in a new tab)
Accessed 9 Sept 2026
- Help centerOpenAI
Developer mode and MCP apps in ChatGPT (opens in a new tab)
Accessed 9 Sept 2026
- Help centerOpenAI
Apps in ChatGPT (opens in a new tab)
Accessed 4 Sept 2026
- Help centerAnthropic
Getting started with custom connectors using remote MCP (opens in a new tab)
Accessed 28 Jul 2026
- Help centerGoogle
Connect custom apps to Gemini Spark with MCP (opens in a new tab)
Accessed 9 Sept 2026
- Secondary referenceOWASP GenAI Security Project
A practical guide for securely using third-party MCP servers (1.0) (opens in a new tab)
Accessed 9 Sept 2026
- Secondary referenceOWASP Cheat Sheet Series
MCP security cheat sheet (opens in a new tab)
Accessed 9 Sept 2026