Claude connector approval checklist

Your printable connector approval checklist

Each item is a question the approver should be able to answer with a name, a setting or a document, not with an assurance. The blank line is for the owner, the decision and the evidence that supports it.

1. 1. Business owner and use case

   Name the person accountable for the outcome and write the one question or workflow the connector serves, for example answering invoice status questions for accounts payable or summarizing opportunity changes for a weekly forecast review. A connector without a named owner and a bounded use case is not ready for approval.

   Owner / decision / evidence:

2. 2. Identity and per-user authorization

   Confirm that each user signs in to the source system under their own identity and that the connector or MCP server acts with that user's permissions, not with a shared service account. A shared credential gives everyone who uses the connector the access that credential has.

   Owner / decision / evidence:

3. 3. OAuth scopes and least privilege

   List the scopes the connector requests and remove any the use case does not need. Prefer a server that starts with minimal read scopes and asks for more only when a specific operation needs it. Record who approved the final scope set and on what date.

   Owner / decision / evidence:

4. 4. Read versus write tools

   Separate the tools that read records from the tools that create, update, send or post. Approve read tools first. Keep write tools disabled until the approval step for actions exists in your governance framework, and keep them disabled in any mode where the assistant can call tools without asking you first.

   Owner / decision / evidence:

5. 5. Data classification and exclusions

   State which data classes the connector may reach and which are excluded, such as payroll, health, card or personal data, and name where each exclusion is enforced: a source-system role, a server-side filter, or both. An exclusion that exists only in a prompt is not a control.

   Owner / decision / evidence:

6. 6. Logging and evidence

   Confirm what the server logs for each call (user, tool, parameters, records touched, time) and that an answer used for a decision can show the query it ran, the metric definition it applied and the policies in force. Agree who reviews the logs and how often.

   Owner / decision / evidence:

7. 7. Retention and training-data commitments

   Read the vendor's own page for the plan you are on and record what it says about retention of prompts, outputs and connector data, and whether your data is used for model training. Record the URL and the date you checked it. Do not rely on a sales deck or a summary.

   Owner / decision / evidence:

8. 8. Vendor status and support

   Record who builds and maintains the connector or MCP server (the system vendor, a partner, an open-source project or your own team), its support status, how you will learn about changes and who patches it. Services reached through a custom connector are not verified by Anthropic, so treat them as part of your supply chain.

   Owner / decision / evidence:

9. 9. Testing with reference questions

   Before enabling the connector for a group, run a set of reference questions with reviewer-approved answers, including questions that should be refused, return no data or stop at a permission boundary. Keep the question set and the results as evidence attached to the approval.

   Owner / decision / evidence:

10. 10. Revocation and offboarding

    Confirm how access is revoked when a person leaves or changes role, and that removing their access in the source system removes the connector's access for them as well. Test it with one account before approval rather than assuming it.

    Owner / decision / evidence:

11. 11. Change control

    Agree who may change the server URL, scopes, tool list or model settings, how changes are announced and which changes require re-approval. A connector whose tool behavior changes without notice should be treated as a new connector.

    Owner / decision / evidence:

12. 12. Incident contact

    Name the person to call when the connector returns wrong data, a prompt injection is suspected or an unexpected action occurs, and write down the first three steps: disable the connector, preserve the logs, notify the owner. Rehearse it once before go-live.

    Owner / decision / evidence:

Where the controls live

The controls on this checklist sit in three places: the source system, the MCP server and the Claude admin settings. An approval that names which place enforces each item is far easier to audit than one that assumes the assistant will behave.

In the source system

Per-user authorization (item 2) and data exclusions (item 5) belong here first. In NetSuite that means the role each user is assigned and the permissions and restrictions attached to it. In Salesforce it means profiles, permission sets, field-level security and sharing rules. In Oracle Fusion Cloud it means the job roles a user holds and the data security policies that scope them, for example to a business unit or a ledger. If the source system allows a user to see a record, a connector acting as that user will see it too, so fix the role before you approve the connector. The same is true for revocation (item 10): removing access in the source system should be the control that ends the connector's access.

In the MCP server

Scopes (item 3), the read-versus-write split (item 4), server-side exclusions (item 5) and logging (item 6) live here. The MCP specification's security best practices set the baseline an enterprise should expect from any server it approves: the server must only accept tokens issued to it and must never pass a client's token through to the downstream API; a server that proxies to a third-party API through one static client ID must keep a per-user registry of approved clients and show a consent page that names the client, the scopes requested and the redirect address; and scopes should start minimal and grow only when an operation needs more. Ask the server owner to show where each of these is implemented, and ask for logs that carry the user and a correlation identifier for every tool call. A governed server also carries business meaning: Nexatron, for example, exposes governed query tools to any MCP client and returns with every answer the query it ran, the certified metric definition and the row-level policies applied. See Nexatron for the current connector status before relying on a specific source.

In Claude admin settings

Who may add a connector, how users authenticate to it and which tools are enabled (items 2, 4, 8 and 11) are set here. Anthropic's support article on custom connectors using remote MCP is the source of truth. As of 2026-10-09 it states that on Team plans only Owners and Primary Owners can add a custom connector to the organization, that on Enterprise plans Owners, Primary Owners and people with a custom role that includes Manage access to Libraries can do so, and that each member then connects to and enables the connector individually. It warns that a shared credential such as an API key gives everyone who uses it that credential's access, that a user should click "Allow always" only for a server and tool they trust to run unsupervised, that a user can disable individual tools from the Search and tools menu, and that in Research mode Claude can invoke connector tools without further approval, which is the reason item 4 keeps write tools off. It also notes that remote connections originate from Anthropic's cloud infrastructure, so a server on a private network must allow Anthropic's IP ranges, that a connector cannot be edited in place and must be removed and re-added with the new details (a change-control event for item 11), and that custom connectors reach services Anthropic has not verified. Re-check the article before approval; plan features change.