Do I need an API key to use security tools in my AI chat plan?

Not always. An MCP security connector can sign you in with OAuth, so you approve access in a browser and no key is pasted anywhere. Some connectors instead send a fixed credential, such as an API key, as a request header. Ask the vendor which model it uses before you buy.

Two things people mix up

A chat subscription and a security tool are separate accounts. The chat plan gives you the assistant. The security tool holds your findings. MCP is the plug between them, so you need access to both, and the connector decides how the second one is proven.

The MCP introduction describes the protocol as an open standard for connecting AI applications to external systems. It says nothing about replacing the credentials of those systems. Your security data stays behind the security tool's own sign-in.

The three sign-in patterns you will meet

Claude's help center describes the first two for custom connectors: sign in now, sign in when needed, or no sign in, with fixed credentials sent as request headers. It also notes that on Team and Enterprise plans a connector using a shared credential gives everyone that credential's access.

What the MCP specification says

For HTTP based servers, the authorization section recommends OAuth and says clients must send the token in an Authorization header on every request. For local servers that use the stdio transport, it says implementations should not follow that flow and should retrieve credentials from the environment instead. So a local setup usually means a key in an environment variable, while a remote setup usually means a browser sign-in.

How to decide

1. Prefer OAuth for any connector that exposes findings about real systems. Access follows the person, and revoking it is cleaner.
2. If a shared key is the only option, create it with the narrowest permissions the vendor offers and give it an owner.
3. Never paste a key into a chat message. A connector setting is the right place, a conversation is not.
4. Write down who can rotate the credential, and how often.

What to ask the vendor

• Does the connector support OAuth, and which scopes does it request?
• If it uses a key, can the key be limited to read operations?
• Where does a revoked user lose access, in the chat tool or in your security tool?

Treat the answers as part of the purchase decision, because they define who can see your vulnerability data through a chat window.

A worked example: three teams, three answers

These are illustrative setups, not real customers.

Team A, five engineers, remote connector with OAuth. The lead opens the chat app, adds the connector address, and clicks sign in. A browser tab opens on the security vendor's page. Each engineer signs in with their own account and sees a list of permissions. One person declines a write permission that the first question does not need. Nobody pastes a key. When one engineer leaves, their access at the security vendor is removed, and the connector stops working for that person only.

Team B, twelve people, connector with a fixed header credential. An administrator creates one key at the vendor, pastes it into the connector settings once, and every member can then use the connector. It is quick. It also means the vendor's logs show one identity for twelve people. The team writes down who owns the key, sets a rotation reminder, and asks the vendor for a read only key.

Team C, a developer who wants a local helper. She installs a local server on her laptop and sets an environment variable with her token. No browser sign in happens, because the specification expects local servers to read credentials from the environment. The risk is that anything else running as her can read that variable, so she keeps the token narrow and never commits it to a repository.

A step by step way to find out for your own vendor

1. Ask the vendor for the connector's address and whether it is remote or local.
2. Ask which sign in method it supports and request a screenshot of the consent page.
3. Ask whether the connector can be set up with OAuth for each user, and whether a shared key is the only way to use it in a team plan.
4. Create a test account at the vendor with no real data.
5. Connect from a free or trial chat account and watch what the sign in asks for.
6. Check the vendor's access list afterward. You should see the test user, with the scopes you approved.
7. Revoke the test user and confirm the connector stops returning data.

What you pay for and what you do not

This post does not discuss prices. The practical point is that three things can each have their own terms: the chat plan, the security tool, and any usage limits on connectors. Plan features and limits change, so confirm what your plan allows on the provider's page. Claude's help center, for example, lists connector availability by plan and notes that Free is limited to one connector.

Mistakes teams make

• Treating a chat subscription as if it already includes access to the security tool. It does not. You need an account at the vendor.
• Pasting an API key into the conversation to make a connector work. Keys belong in connector settings or environment variables, not in messages that the provider processes and may store under its own terms.
• Using a personal admin credential for a team connector, so every action looks like it came from one person.
• Forgetting to remove access when someone changes role.

A short decision table

Whichever you choose, record it in your connector register with an owner and a review date.

Where Safeguard fits

If you want to see what findings look like before deciding anything, the free scan at gold.safeguard.sh/scan produces a result you can inspect without connecting an assistant. Safeguard also offers an MCP Guardrail for teams that want controls around the tools agents can call.

Try it yourself

Click through it at your own pace, or open it full screen.

Click through the setup and look for where credentials are supplied and which tools become available once access is granted.

Quick check

Sources

• MCP introduction
• MCP specification, authorization
• Claude Help Center, custom connectors using remote MCP

Last reviewed: 19 October 2026.