MCP Security for Teams: Is It Safe to Install AI Apps?

MCP security comes down to a simple truth: an AI assistant is reasonably safe on its own, and the real risk arrives with what you install and which permissions you grant it. When you connect an MCP server to Claude, ChatGPT, or Cursor, that connector can read and, where permitted, act on real data - so the safety of the whole setup is heavily shaped by what someone approves and how it is managed afterwards, not by the assistant alone. This guide gives teams the plain-language risks, an 8-point checklist, and what the assistants do and don't protect.

• Risk lives in the install, not the assistant. Each connector can read and, where permitted, act on real data; you decide the safety when you approve it, set its scope, and keep managing it afterwards.
• Five risks to know: prompt injection through tool output, over-broad scopes, secrets pasted into prompts, unvetted local servers, and silent changes to a server's behavior.
• OAuth 2.1 beats a pasted API key on scope, expiry, and clean revocation - always ask a vendor which scopes their server requests.
• Run the 8-point checklist first. If two or more items fail, pilot with one person on a test account before granting the team access.
• Read-only earns trust quickly; write access earns it one approval at a time. Keep human approval on for any tool that changes data.

Why MCP Security Starts With What You Install

Think of B77 as the App Store for your AI assistant, and MCP security the same way you'd treat a phone: the assistant is reasonably safe on its own, but the risk comes from what you install and which permissions you grant. When you install apps in your AI assistant, each one can read and, where permitted, act on real data, so MCP security is shaped by what you approve and how you manage it afterwards, not by the assistant alone.

A few terms, once: MCP (Model Context Protocol) is the open standard that lets Claude, ChatGPT, or Cursor call outside tools. An MCP server is the "app" you install. A tool is one action that app exposes, for example, "list campaigns."

This is written for the person who has to sign off - a product manager or IT lead approving connectors for a team, without the time or access to audit source code. The rest of the article covers the risks in plain terms, an 8-point checklist you can copy, two walk-through scenarios, and what the assistants themselves protect.

Five MCP Security Risks, Explained in Human Terms

Most MCP security risks are not exotic. They are ordinary failures of trust and scope, dressed up in new vocabulary. Here are the five worth understanding before you connect anything to your team's assistant.

1. Prompt injection through tool output. Prompt injection is when text the assistant reads - a web page, a support ticket, a document a tool returns - contains hidden instructions, and the assistant follows them as if you had typed them. Anthropic's connector documentation (checked 2026-09-01) warns that malicious MCP servers "may include hidden instructions that try to make Claude perform unintended actions." OpenAI's MCP documentation (checked 2026-09-01) adds that attackers may exploit write actions to send sensitive data to external destinations. On a team, that looks like a fetched ticket quietly telling the agent to email a customer list somewhere.

2. Over-broad scopes. A scope is the specific permission a token grants - "read invoices," say, rather than "do anything." The MCP Security Best Practices document (spec revision 2026-07-28) lists wildcard or omnibus scopes such as all or full-access among common mistakes. The problem is blast radius: one stolen broad token reaches everything at once, so a small leak becomes a full compromise.

3. Secrets pasted into prompts. When someone types an API key into a chat to "connect" a tool, that key now sits in the transcript and in whatever logs the platform keeps. Many keys are hard to scope down or limit to one action, and often the only way to "revoke" one is rotating it at the source - which breaks everything else using it.

4. Unvetted local servers. The same best-practices document states that local MCP servers run with the same privileges as the client, and asks clients to show the exact startup command before executing it. In plain terms, an unvetted local server can do anything your logged-in account can do on that machine - unless the client sandboxes or otherwise restricts it, which the best-practices document recommends but does not guarantee. Read the startup command before you approve it.

5. Silent changes. A remote server's tool list and descriptions are fetched from the operator's server, so the operator can change what a tool does after you first approved it - without your team being asked again. A connector you trusted last month may behave differently today.

None of these is fixed by picking a "safer" assistant; they are fixed by what you install and how you scope it.

Security teams describe the same five in their own vocabulary: vulnerabilities in tool execution, unauthorized access through a leaked token, and attack patterns that only show up in monitoring after the fact. Most of the defense, though, is decisions rather than new infrastructure of your own: the platform you choose should already implement audit logging and monitoring, and the checklist below tells you what to verify.

MCP Authentication: Why OAuth 2.1 Beats a Pasted API Key

That last point about scope leads straight to authentication. MCP authentication is how an MCP server confirms who you are and what you're allowed to do before it runs any tools on your behalf. In the MCP specification revision 2026-07-28 (modelcontextprotocol.io, checked 2026-09-01), authorization is optional and defined for HTTP-based transports - the way most hosted MCP servers you connect to a cloud assistant actually work.

When a server does use it, MCP OAuth is built on the OAuth 2.1 draft (an IETF specification that modernizes the older OAuth 2.0 sign-in standard). A few requirements matter to you as a team:

• PKCE is mandatory. PKCE (Proof Key for Code Exchange) is a one-time secret the client generates so that an intercepted login code can't be redeemed by anyone else.
• Tokens are bound to one server. Access tokens must be tied to the specific MCP server they were issued for via the resource parameter (RFC 8707), and a server must not accept or forward a token meant for another service. This "token passthrough" is explicitly forbidden.
• Least privilege by design. The spec asks servers to advertise only the minimal scopes an operation needs (for example, files:read) and to ask for more with a step-up challenge when a specific action requires it.
• Short-lived tokens. Authorization servers should issue access tokens that expire quickly.

In plain terms: with OAuth you sign in on the service's own page, so the assistant never sees your password (that's Anthropic's own wording for custom connectors). The grant is scoped to specific permissions, and you can revoke it from either side - the assistant or the service.

Compare that with a pasted API key on three points. Scope: a key often carries whatever permissions the account has rather than the narrow slice you intended - scoped, expiring keys exist, but they are the exception in practice. Expiry: a key sits there until someone rotates it; OAuth tokens expire on their own. Revocation: killing a key often means regenerating it and breaking everything that uses it, while an OAuth grant can be cut cleanly.

Before you connect anything, ask the vendor one question: "Do you support OAuth for this MCP server, and which scopes does it request?"

The 8-Point MCP Security Checklist Before You Connect

Before you wire any MCP server into a shared assistant, run this MCP security checklist. Each point takes about five minutes to verify, and you can paste the whole list straight into a ticket. If you have ever asked "are MCP servers safe?", the honest answer is: it depends entirely on the eight things below.

1. Require OAuth 2.1, not a pasted API key. OAuth 2.1 is the sign-in flow where you authenticate on the service's own page; confirm the connection opens that page in a browser and that no key ever appears in the chat window.
2. Insist on least privilege. Check the requested permissions and confirm the server asks for read-only scopes where the workflow allows, reserving write scopes for the specific tools that genuinely need them.
3. Identify who operates it. Look for a named company with published terms, a security contact, and a documented way to report a problem - not an anonymous handle.
4. Know where it is hosted and what is retained. Find the hosting region (EU or not) and whether the server stores your requests or proxies them live, and get that in writing on the listing or docs.
5. Confirm there is an audit log. Verify you can see who called which tool, at what time, and from which client, so an incident is traceable rather than invisible.
6. Test the revoke path. Make sure you can disconnect both from inside the assistant and from the service's own security settings, and actually confirm both cut access.
7. Use a vetted catalog. The server should come from a catalog with a review step and a visible permissions description, never from a raw URL someone dropped into a chat message.
8. Keep a human in the loop for writes. Ensure approval prompts stay on for any tool that changes data, and reserve "always allow" for read-only tools you already trust.

Score it honestly. If two or more items fail, do not connect the server for the whole team. Pilot it first with a single person on a test account, watch the audit log, confirm you can revoke cleanly, and only then decide whether it earns broader access.

Two Scenarios: A Read-Only Report Connector and a Write-Scoped Ads App

Abstract risk lists only get you so far. Here are two typical situations a marketing team meets, run through the checklist so you can see where the line sits.

Scenario A: A read-only web-analytics report connector

A marketing lead wants their assistant to pull traffic and conversion reports so they can ask questions in plain language instead of building dashboards. Walking the checklist, this one passes cleanly:

• Scopes: read-only - the server can fetch report data and nothing else.
• Operator: named and identifiable, so you know who runs the server.
• Sign-in: OAuth (an authorization standard where you log in at the provider and grant scoped access, instead of handing over a key).
• Revoke path: you can withdraw access from the provider's account settings at any time.

The residual risk is prompt injection: text inside a returned report or crawled page could contain instructions aimed at your assistant. Because the connector is read-only, that text cannot change anything through this connector's own tools - but it can still try to steer the assistant into using another, write-scoped tool available in the same conversation. The safe rule is simple - the assistant summarizes, a human acts. Decision: connect it. Owner: the marketing lead, who reads the summary and makes the call.

Scenario B: A write-scoped Google Ads app

Now the same team wants to change campaigns from chat. That means write access, which is a different risk class. Using the Google Ads app's published permissions on B77 (page checked 2026-09-01), in its own words:

• Reads: "Your Google Ads campaigns, keywords, and performance metrics"
• Writes: "Only the changes you ask for - budgets, keywords, ads, campaign status"
• Never sees: "Your other apps, files, or accounts you didn't connect"
• Storage: "Nothing stored - each request talks to the Google Ads API live"
• Connection: OAuth to a Google account - no API key to paste.

Here checklist item 8 does the heavy lifting: keep tool approval on for every write tool. Read the proposed change before allowing it - which campaign, which budget, which status. Never choose "always allow" for writes. Decision: connect, but approve each write by hand. Owner: the human approver who confirms the change - not the assistant.

So, is MCP safe? It depends less on the protocol and more on the scope you grant and who signs off. Read-only earns trust quickly; write access earns it one approval at a time.

What Claude and ChatGPT Protect on Their Side, and What They Don't

Those approvals live inside the AI host - Claude or ChatGPT - which sits between you and any MCP server. Both vendors ship some controls, but treat them as a floor, not a guarantee. The facts below are current as of 2026-09-01; check the vendor docs before you rely on them.

Claude

Per Anthropic's custom connectors article (support.claude.com), custom connectors are available on Free, Pro, Max, Team and Enterprise plans, with Free limited to one custom connector. On Team and Enterprise, only Owners can add a connector; individual users then connect to and enable it themselves - a useful split between admin controls and personal opt-in, and the same flow applies to third-party Claude MCP connectors from a marketplace. Anthropic states plainly that custom connectors reach services "that have not been verified by Anthropic." Claude has built-in protections that "attempt to block" hidden-instruction attacks, but Anthropic advises you to review each tool approval request and only click "Allow always" for tools you trust to run unsupervised. You can revoke access by disconnecting the connector in Claude's settings, or in the third-party service's own security settings.

ChatGPT / OpenAI

OpenAI's MCP documentation (developers.openai.com) says custom MCP servers "are not developed or verified by OpenAI." It recommends keeping approval enabled for any tool that can modify data or take other consequential actions, limiting how many people can access MCPs holding particularly sensitive data, and reviewing write actions carefully. It also notes that any MCP server may receive sensitive data as part of a query. Harmful servers can be reported to [email protected].

So, are ChatGPT connectors safe? A connector is only as safe as the server behind it and the scopes you granted - the client's checks don't vouch for either. Exactly which of your data Claude can read through a connector depends on the scopes you approve, and is covered in our explainer on Claude connectors.

How B77 Handles Credentials, Logs and Curation

To make the checklist concrete, here is how one hosted marketplace handles the pieces that matter. These claims come from b77.ai/security (checked 2026-09-01).

Every connection between your assistant and a B77 app is authorized with OAuth - the standard that lets you grant access without handing over a password. Tokens are scoped to your account, never shared between users, and revocable from your B77 account at any time. Some apps also need their own credentials (an upstream token or service key). Those live in a credential vault: encrypted per user with a data-encryption key held in the platform's secret store, used server-side only, and never returned to the assistant. The model that drafts your message never sees the underlying key.

Every authenticated tool call is logged for usage audit - who made it, when, which tool, and from which client. A shared connection logs both identities: the person who made the call and the person whose access it ran under. The platform and the apps it operates run in EU data centres in the Frankfurt and Helsinki regions; handling is GDPR-aligned with no silent retention. Each app page carries a "What this app can see" block listing what it reads, writes, never sees, and stores, so the B77 catalog is legible before you connect.

The honest trade-off: with a hosted marketplace, the operator holds the grants - so checklist item 3 applies to the marketplace itself: check who operates B77 the same way you would check any vendor. A team that must self-host keeps the tokens but inherits the patching, logging, and revocation work in return.

MCP Security FAQ

Are MCP servers safe to use at work?

It depends on who operates the server, what scopes it asks for, and whether you keep approvals turned on. A hosted server from a reputable operator with read-only scopes and per-action confirmation is a very different risk than an unvetted local server running with broad permissions. Run the checklist before you connect, and the question mostly answers itself.

What are the most common MCP security risks?

The usual MCP security risks are prompt injection through tool output (malicious text a tool returns that tries to steer the assistant), over-broad scopes that grant more access than the task needs, and pasted secrets that end up in logs or chat history. Add unvetted local servers running with wide permissions and unannounced changes to a server's behavior, and you have the short list worth guarding against.

What is the difference between MCP authentication with OAuth and an API key?

OAuth 2.1 grants scoped, expiring access that you can revoke at any time, and the assistant never sees your password. A pasted API key is typically long-lived, hard to scope narrowly, and sits in plain text wherever you put it. That combination of limited scope, expiry, and clean revocation is why OAuth is the safer default.

Are ChatGPT connectors safe?

ChatGPT connectors are only as safe as the server behind them and the approvals you leave switched on. OpenAI does not verify custom third-party servers, so you are trusting the operator and the scopes you granted, not a stamp of approval. Keep action confirmations on and treat an unknown connector the way you would any unvetted software.

Can I revoke an MCP connection after I grant it?

Yes. You can remove the connection from your assistant's settings, and you can also revoke access on the service or marketplace side where the token was issued. Check both places, because clearing one does not always clear the other.

The Bottom Line

Safe MCP use is a decision you make at install time, not a property of the assistant. Require OAuth 2.1, insist on least-privilege scopes, know who operates the server and where it's hosted, keep audit logs and a revoke path, and keep a human approving every write. Score any connector against the eight points above before it reaches the whole team. If you'd rather start from a vetted catalog where OAuth, scoped tokens, per-call audit logs, and a plain "What this app can see" block are already in place, browse the hosted apps on B77 and connect one to your assistant - then run the same checklist to confirm it earns the access. Browse hosted MCP servers and connect one to your assistant in a couple of clicks: the B77 marketplace.