MCP Control Plane
The MCP Control Plane governs MCP interactions across your organization, including MCP servers you compose in Workato, Workato prebuilt MCP servers, and third-party servers integrated by proxy. The MCP Control Plane enforces authorization, manages traffic limits, captures audit and observability data, and applies governance policies uniformly across the entire MCP estate.
Gateway
Gateway is the central enforcement point for all MCP traffic. Every client connection passes through it, and every tool invocation is authenticated, authorized, and rate-limited before reaching the runtime.
Authentication and access control
Each MCP server uses:
Authentication: End users must authenticate to provide their identity to the MCP server.
Authorization: Establishes what the authenticated user is allowed to do, both at the server level and in the underlying tool's backend.
| Methods | Use | |
|---|---|---|
| Authentication | • API token • Username and password (Workato Identity) • SSO (external IdP) | API token: Single shared credential. Development, testing, headless service access. Username and password: End user signs in with Workato Identity credentials. SSO: End user signs in through their IdP, such as Okta, federated to Workato Identity. |
| Authorization | • End-user groups • Verified User Access (OAuth 2.0) | End-user groups: Server-level authorization determines which MCP servers a user can reach. Verified User Access: Per-user authorization to the underlying tool's backend connection. |
Authentication
Each MCP server uses one of three access methods:
API token (default): This method uses a Workato-issued token. Workato recommends this method for development, testing, or scenarios that don't require SSO. Revoking a token immediately disconnects all clients using it.
Username and password (Workato Identity): End users authenticate with their Workato Identity username and password when connecting from MCP clients, such as Claude, Cursor, or Windsurf.
SSO (external IdP): End users authenticate through your organization's identity provider, such as Okta, federated to Workato Identity. This provides a single sign-on experience across MCP clients in which users sign in once through their organization's IdP to access Claude, Cursor, Windsurf, and other MCP clients.
Refer to MCP access methods for more information.
Authorization
Workato MCP provides authorization at two layers:
Server-level authorization with end-user groups: Controls which MCP servers a user can access.
Per-user backend authorization with verified user access: Controls what the user can do on the underlying tool after accessing an MCP server.
End-user group server-level authorization
End-user groups provide server-level authorization and determine which MCP servers each authenticated user can access. You can manage groups in Workato Identity.
ALL USERS MUST BE ADDED TO A USER GROUP
Workspace owners, admins, and collaborators aren't automatically granted MCP server access. You must add all users, including yourself, to an end-user group. Admin privileges are required to grant end-user access.
Refer to User group MCP server access for more information.
Verified user access per-user backend authorization
End-user groups govern access to the MCP server. Verified user access governs access to the underlying tools. OAuth 2.0 authentication propagates the user's identity to the underlying tool's backend connection after the end user is authenticated to the MCP server. This ensures backend calls to Salesforce, Gmail, and other tools execute under the calling user's identity and permissions rather than a shared service account.
MCP verified user access
Verified user access works through runtime user connections and allows each end user to authenticate with their own credentials when accessing a tool that requires authentication. This ensures that workflows perform actions using the identity and permissions of the individual user. Refer to MCP verified user access for more information.
Traffic management
You can add custom rate limits, usage quotas, and IP restrictions to your MCP server.
Rate limits control how quickly requests can be made, acting as a throttling mechanism to prevent bursts of traffic. For example:
Hourly throttling
- Time interval:
1 hour - Tool calls:
5,000 - Result: The MCP server accepts up to 5,000 tool calls per hour across all users. This prevents sudden spikes that could overwhelm your backend systems.
Usage quota controls the total cumulative consumption over a period of time, restricting the capacity limit to manage overall resource consumption. For example:
Monthly usage quota
- Time interval:
1 month - Tool calls:
1,000,000 - Result: Your MCP server has a monthly usage quota of 1 million tool calls. All requests are blocked until the monthly quota resets after this limit is reached.
Refer to Configure MCP server limits for more information.
Proxy to third-party MCP servers
Proxy servers enable MCP clients to connect to remote third-party MCP servers through Workato, using Workato Identity to verify each user before routing requests to the external system.
You can use verified user access with proxy MCP servers. This allows you to route requests to external systems like Salesforce or Snowflake with each user authenticating with their own credentials. Users are prompted to sign in to the external system the first time they connect, and Workato handles the rest automatically. Refer to Create a proxy MCP server for more information.
Observability
Observability for MCP runs is provided at the server-level with activity logs and at the tool-level with execution traces.
Server-level logs
Server-level logs show activity for every tool call an MCP server receives. Each entry captures the calling user, authentication method, source IP, user agent, tool name, invocation inputs and outputs, duration, and success or failure status. Logs can be filtered by time period, log type, log level, data fields, and recipe ID.
You can stream logs to any Security Information and Event Management (SIEM) app.
Refer to View MCP server logs for more information.
Tool execution traces
Each tool invocation produces a recipe job in the recipe's job history. The job shows the full step-by-step execution, including actions, connections, input and output between steps, and any errors encountered. The calling user's identity, including the user name, user email, and user group IDs, is propagated into the job context. This enables backend actions the recipe takes to be attributed to the user that initiated the MCP call.
End-to-end traceability
Server-level logs and tool execution traces provide end-to-end traceability for any MCP interaction. The activity log captures every request entering the Gateway. The recipe job history captures every downstream action the request triggered. Both layers obtain the calling user identity to allow a single MCP tool call to be traced from the Gateway, through the recipe execution, and into the backend systems it touched, all linked by the user that initiated it.
Governance
MCP provides RBAC permissions and an audit trail for administrative actions.
RBAC permissions
Granular RBAC permissions are used to assign user privileges to create, edit, delete, and manage MCP servers. Refer to Manage your workspace collaborators with role-based access control for more information.
Audit trail
Every administrative action is logged with the actor, the resource, and the change set:
- Servers: Created, renamed, or deleted
- Tools: Added, removed, started, or stopped
- Policy changes: IP allow and deny lists, rate limits, and quota limits
Activity audit
Last updated: