MCP approvals, roles, and connections
Understand project selection, approval-gated changes, audit records, Operator Units, and optional service accounts for Chat4U MCP.
3 min read
- Account menu
- MCP
- Connections
Review connection state in MCP settings; project-scoped operations and their approvals are then surfaced in the MCP client’s returned approval flow.
- Read onlyRead
Policy-filtered project data and safe aggregate views.
- ConfirmConfirm
Review the exact proposal and approve before it executes.
- Strong approvalStrong approval
Sensitive or destructive tool operations require the extra safeguard.
MCP preserves Chat4U control-plane boundaries instead of granting a connected AI client unrestricted dashboard access.
Prepare, review, execute, audit
Prepare the exact requestCall the write tool with a unique client_request_id and fixed parameters.
Chat4U validates membership, role, capability, project entitlement, and inputs before storing a durable preview.Review the proposalUse the client form or returned first-party approval route.
An authorized workspace member reviews the target; sensitive changes can also require a phrase or authority attestation.Resume the unchanged requestReuse the same request ID and arguments only when the client prompts you.
Chat4U verifies that approval and target still match, then executes the action once.Check the audit outcomeUse chat4u_action_get rather than assuming execution.
The proposal, decision, actor, execution outcome, and audit events remain available in Chat4U.
The approval is not a blank cheque. A new or changed request, stale target, denial, expired approval, or failed execution does not apply a change; prepare a new proposal and review it again.
Roles and project entitlements
OAuth identity establishes which workspace can be used. Active workspace membership and local Chat4U role policy determine what the user may access. Administrator/owner policy is required for manage-level capabilities; individual capability definitions can impose narrower role restrictions. Each protected project is checked against the active commercial plan version and its current entitlement, including MCP reads, MCP actions, and Operator Units.
This means a client can be connected successfully yet receive a clear project_required, project_not_found, project_forbidden, entitlement, or allowance error for a specific request. Resolve the project and plan rather than bypassing the error with a different account.
Operator Units
Successful project-scoped reads cost one Operator Unit. A successful approved MCP write costs two. Chat4U reserves usage before the protected operation and commits it only on success, so a failed or rejected operation should not be presented as successful consumption. Discovery and authentication are free.
Optional service accounts
Organization API keys are a separately enabled MCP capability, not the default sign-in path. A valid service account is explicitly scoped, has a bounded expiry in the deployment policy, carries a role, and is bound to a single chat4u_project_id. It can only reach that project when the project plan includes service-account access. It cannot approve an action or supply human approval evidence.
Do not put a service-account token in source control, prompts, browser configuration, or tickets. Revoke it from Dashboard → Settings → MCP and API keys when no longer needed.
Connections and revocation
Chat4U records an MCP connection on use, including its credential type, organization/workspace binding, capability snapshot, and last-use time. The settings page lists these connections and supports approval-gated disconnect and restore actions. A disconnected connection is denied by the service even if its local client still has a token.
Last updated on