Skip to content

Enterprise AI

MCP connectors

Connect ten supported enterprise services to governed Cortex workflows.

Enterprise AI currently exposes ten connector families through MCP. A connector makes a governed set of service tools available to eligible Cortex sessions; it does not copy the connected service into Cortex or grant new permissions.

Connector Enterprise services and supported work
GitHub Repositories, code, issues, pull requests and releases
Atlassian Jira work items and Confluence knowledge
Slack Channel and user context, search and approved messaging
Microsoft 365 Outlook mail and calendar, Teams, OneDrive and Excel
Google Workspace Gmail, Calendar, Drive and Docs
AWS Scoped AWS service operations using an approved identity and region
Microsoft Azure Infrastructure, storage, data, monitoring, messaging and AI services
Azure DevOps Repositories, work items, pipelines, wiki and test plans
Salesforce Object metadata, read-only SOQL and search, plus permitted record, account, contact, opportunity and case operations
Google Cloud Project-aware Google Cloud operations exposed by the approved MCP service

The Salesforce connector supports governed create and update operations where enabled; record deletion is not exposed. Tool availability can be narrower than this table because the tenant, user role, provider scopes, plan and active workflow all apply.

GitHub and Azure DevOps connect source, pull requests, issues or work items, pipelines, releases and supporting project knowledge. Atlassian connects Jira planning and Confluence documentation. Cortex keeps the source service’s repository, project and record permissions intact.

Slack, Microsoft 365 and Google Workspace connect communication, calendars, documents and files. An authenticated connection does not imply access to every channel, mailbox, drive or document; the provider evaluates access for the acting identity.

AWS, Microsoft Azure and Google Cloud expose eligible infrastructure and operational tools with a scoped project, subscription, account or region. Salesforce connects customer and revenue context with supported object and record operations.

  1. An administrator enables the connector entitlement for the organization.
  2. An eligible user or deployment authorizes the enterprise service with OAuth, a service account or another approved credential type.
  3. Cortex shows the operations available to that user and connection.
  4. The user requests an eligible operation; consequential writes can require approval.
  5. The result returns to the active Cortex session with an auditable operation record. Provider credentials are not inserted into prompts.

The client distinguishes services selected for a task from services with an active authenticated connection. If authorization expires, reconnect the same service identity; Cortex does not fall back to another account. If an expected tool is absent, check the organization entitlement, plan, provider scopes, resource permissions and whether that tool is allowed on the current surface.

Read and write availability are independent. A connector can remain useful for search and context while write operations are disabled or approval-gated.

  1. Enable the connector for the tenant.
  2. Choose personal OAuth, service account or another approved credential mode.
  3. Grant the minimum scopes and restrict eligible users or groups.
  4. Test a read-only operation before enabling writes.
  5. Define approval, audit, retention and revocation behavior.

Credentials are protected by the managed connection and are not copied into prompts or client configuration. A revoked connection must be authorized again. Connector and agent counts can change by release; see Release Notes for the shipped set.