Connect FAQs

How does Connect handle user permissions and security?

User context is inherited through OAuth, so permissions are governed at both the connector level (via IDP roles/groups) and the user level. Users can only invoke actions with the maximum permissions their user level has been granted. If a user lacks permission for an action, the Large Language Model (LLM) will respond that they do not have access due to their role. Some connectors also allow API keys to be entered to grant service-level users higher authority.

How do administrators expose connectors to end-users without requiring manual connections?

The administrative user will publish the MCP endpoint on the backend. Other users in the organization will then automatically see the connectors and tools they have access to.

Why should we use Connect as a centralized connector layer rather than using direct MCPs?

Customers generally prefer a single connector layer to manage all auditing and security, especially when using multiple AI tools (such as Claude and OpenAI) across different departments. The Connect platform is designed to be "out of the box," standard, and tuned for performance and security for knowledge workers, without requiring the manual creation or wrapping of MCP endpoints. Connect also provides governance and observability for which tools are being called by whom, along with tool scoping, etc.

Can we control access to specific tools within a large system like Salesforce?

Yes, you have granular control at the tool level. You can create multiple connectors for a single system (like Salesforce) to target different user groups with distinct permissions, linked to specific Identity Provider (IDP) roles.

What is the implication of bundling connectors as an Anthropic plugin?

When users install the plugin, they will likely be asked to complete a one-time authentication with their Identity Provider (IDP), similar to consuming a custom MCP server protected by identity.