Currently, permissions are scoped to users and roles, but there is no way to restrict an action to specific invocation channels (e.g., UI only vs. MCP). This is a concern for high-risk operations such as production deployments, where teams want the additional guardrails and visibility that the Port UI provides.

Relying on the Claude/MCP client config to restrict actions is fragile — it lives outside Port's governance model, isn't auditable in Port, and can be bypassed or misconfigured. Native support in Port ensures consistent enforcement across all MCP clients and aligns with existing RBAC patterns.

Adding an invocation source control at the action level in Port, allowing admins to configure which channels an action can be triggered from would allow teams to enforce that sensitive actions (e.g., prod deploys, destructive operations) cannot be triggered via MCP, without needing to rely on external configuration in the AI client (e.g., Claude system prompt restrictions).