# Separate client work with xCloud teams Plan team and role boundaries for agency operations and client handover. Each invited user sees only the intended team and sites. Canonical: https://xcloud.host/use-cases/playbooks/separate-client-work-with-xcloud-teams/ Published: 2026-09-30 · Updated: 2026-09-30 · Technical review: 2026-09-30 Evidence: Source reviewed; no production deployment test claimed Editorial owner: xCloud editorial Intent: Plan team and role boundaries for agency operations and client handover. For: business-owner, operator ## Requirements and responsibilities - Have named ownership of the domain, selected xCloud team and site, and WordPress administrator access. For this scenario, agree who supplies the data and signs off: An agency has two clients whose site administrators should never view each other's infrastructure. Sources: [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md); [WordPress roles and capabilities](https://wordpress.org/documentation/article/roles-and-capabilities/) - Use a compatible Nginx or OpenLiteSpeed stack for native WordPress. Verify current server resources, plan eligibility and each selected plugin or service license and requirements before installing; a Docker server does not host a new native WordPress site. Sources: [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md); [WordPress plugin administration](https://wordpress.org/documentation/article/manage-plugins/) - Prepare a safe test identity and a completed, accessible backup before consequential changes. The important failure to plan around is: Shared credentials or excessive roles defeat team separation. Sources: [Site backups in xCloud](https://xcloud.host/docs/site-backups-in-xcloud/); [WordPress hardening handbook](https://developer.wordpress.org/advanced-administration/security/hardening/) ## Illustrative situation Illustrative scenario, not a customer case study: An agency has two clients whose site administrators should never view each other's infrastructure. Each invited user sees only the intended team and sites. ## Choose the approach - Choose team boundaries from the actual client ownership and billing model. Verify the selected provider or plugin documentation and license against this requirement; xCloud hosting does not supply its business configuration. Sources: [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md); [xCloud MCP documentation and connection profiles](https://app.xcloud.host/mcp/docs); [WordPress roles and capabilities](https://wordpress.org/documentation/article/roles-and-capabilities/); [xCloud team roles and permissions](https://xcloud.host/docs/team-roles-permissions-in-xcloud/) - Keep application setup, domain/DNS ownership, mail delivery and external integrations with their named administrators. Use a plain documented path when a proposed integration cannot be demonstrated end to end. Sources: [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md); [WordPress plugin administration](https://wordpress.org/documentation/article/manage-plugins/) ## Dashboard and application procedure ### 1. Map client ownership and staff **Where:** xCloud selected team/site resource view and owner planning sheet **Permissions:** Named xCloud team/site administrator; verify the exact target. **Inputs:** Owner, hostname, approved requirements, sample record and decision date. Map client ownership and staff. **Action:** List every client, production site, server, billing owner and staff member. Mark which people may see each team's resources and who approves invitations. **Expected result:** The client-by-client access matrix has a named approver. **Verify:** Compare each hostname and staff identity with the current xCloud resource list. **If it fails:** If a site belongs to two clients or ownership is unknown, resolve it before granting access. Capability: Confirm requirements and inspect resources Sources: [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md); [xCloud MCP documentation and connection profiles](https://app.xcloud.host/mcp/docs) ### 2. Create team boundaries **Where:** xCloud team membership dashboard **Permissions:** Named xCloud team/site administrator; verify the exact target. **Inputs:** Target team/site, server or plugin version, license and documented prerequisites. Create team boundaries. **Action:** In the xCloud dashboard create or select a team per approved boundary and place the intended server or site under its owner. Keep billing and operational ownership explicit. **Expected result:** Each client has a deliberate team boundary. **Verify:** Check team membership and resource ownership from an administrator account. **If it fails:** If ownership differs from the plan, revisit the team design before inviting staff. Capability: Manage xCloud team membership and roles Sources: [xCloud team roles and permissions](https://xcloud.host/docs/team-roles-permissions-in-xcloud/); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md) ### 3. Assign least-privilege access **Where:** xCloud team membership dashboard **Permissions:** Named xCloud team/site administrator; verify the exact target. **Inputs:** Approved change scope, backup state, selected version and maintenance window. Assign least-privilege access. **Action:** Invite named users with the minimum xCloud role needed for their task; keep WordPress editor accounts separate from hosting administration. **Expected result:** Staff can perform assigned work without seeing unrelated infrastructure. **Verify:** Record the role, invitation state and approver for each user. **If it fails:** If a role grants too much access, choose a narrower role or keep the task with an administrator. Capability: Manage xCloud team membership and roles Sources: [xCloud team roles and permissions](https://xcloud.host/docs/team-roles-permissions-in-xcloud/); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md) ### 4. Test each account’s visibility **Where:** xCloud team membership dashboard **Permissions:** Named xCloud team/site administrator; verify the exact target. **Inputs:** Test accounts, sample content or transaction, expected result and provider access. Test each account’s visibility. **Action:** Have each invited user sign in and enumerate visible teams and sites. Ask for a harmless read check on the intended site and a negative check for another client. **Expected result:** Each account sees only approved resources. **Verify:** Compare actual visibility with the access matrix. **If it fails:** If cross-client resources appear, revoke or correct access and repeat the test. Capability: Manage xCloud team membership and roles Sources: [xCloud team roles and permissions](https://xcloud.host/docs/team-roles-permissions-in-xcloud/); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md) ### 5. Review access after changes **Where:** xCloud selected team/site resource view and owner planning sheet **Permissions:** Named xCloud team/site administrator; verify the exact target. **Inputs:** Observed results, unresolved failures, backup point and owner contacts. Review access after changes. **Action:** Set an access-review trigger for departures, contract changes and offboarding. Preserve an owner-controlled emergency account and document revocation order. **Expected result:** Team separation remains valid after personnel changes. **Verify:** Ask the agency lead to review one departed-user account and emergency contact. **If it fails:** If no one owns review, create a real recurring task in the agency's task system. Capability: Confirm requirements and inspect resources Sources: [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md); [xCloud MCP documentation and connection profiles](https://app.xcloud.host/mcp/docs) ## Maintenance - Assign a cadence for selected WordPress core, theme and plugin updates, review version-based findings and retest the path in this guide. In particular, repeat: Each invited user sees only the intended team and sites. A chat prompt is not a scheduled task. Sources: [Manage WordPress updates with Updates Manager](https://xcloud.host/docs/manage-wordpress-updates-with-updates-manager/); [Vulnerability Checker in xCloud](https://xcloud.host/docs/vulnerability-checker-in-xcloud/) - Record actual backup completion, storage access and responsible staff. Recheck connected application and provider behavior after changes rather than relying on a site health status alone. Sources: [Site backups in xCloud](https://xcloud.host/docs/site-backups-in-xcloud/); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md) ## Recovery decisions - If a user can see an unrelated client team, the xCloud team owner should remove the incorrect membership in the dashboard, inspect recent access and retest both positive and negative visibility. Restoring a WordPress database does not repair xCloud team permissions. Sources: [xCloud team roles and permissions](https://xcloud.host/docs/team-roles-permissions-in-xcloud/); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md) ## AI handoff Connect xCloud MCP through the current documented profile and grant only the scopes needed for the selected team. Discover tool schemas first. Read resources to plan; require approval for any supported write. Use returned dashboard URLs for manual work. The packaged REST wrapper accepts GET requests only. ### Supported scope - **Confirm requirements and inspect resources** (mcp; read): Discover the connected profile and operation schema first; only teams granted to the connection are visible. Checkpoint: Confirm exact team, server and site identity. Use dashboard\_url returned by the resource; do not invent a dashboard link. Operation identifiers to discover: teams.index, servers.show, sites.show. Scopes: read:servers, read:sites. Sources: [xCloud MCP documentation and connection profiles](https://app.xcloud.host/mcp/docs); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md) - **Manage xCloud team membership and roles** (dashboard; manual): Team invitations and role changes require an authorized xCloud team owner in the dashboard. A read-only MCP resource view cannot modify access. Checkpoint: Review the exact team, account and role before saving. Sign in as the invited user to verify intended visibility. Sources: [xCloud team roles and permissions](https://xcloud.host/docs/team-roles-permissions-in-xcloud/); [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md) ### Copyable agent brief ```text Help with separate client work with xcloud teams for the exact xCloud team and site I name. First inspect only resources the connection permits and confirm returned identity, stack and relevant versions. Prepare the following authored workflow: Map client ownership and staff; Create team boundaries; Assign least-privilege access; Test each account’s visibility; Review access after changes. Ask the named dashboard, domain, WordPress and application owners to perform operations outside connected capabilities. WordPress staging push/pull, native backup schedules, restore and cache settings remain manual dashboard tasks; the packaged REST wrapper is GET-only. Use the guide’s checks to report observed application evidence, unresolved questions and recovery implications; do not claim completion from a hosting resource read. Acceptance: Each account sees only approved resources. ``` ### Manual checkpoints - The named WordPress, app, dashboard or provider administrator performs the guide’s actual configuration step: Invite named users with the minimum xCloud role needed for their task; keep WordPress editor accounts separate from hosting administration. - The business owner compares the controlled sample with this observable result: Each account sees only approved resources. - Staging push/pull, native backup schedules, restores and cache-setting edits require the authorized xCloud dashboard operator; the packaged REST wrapper is GET-only. ## Feature coverage - **business-acceptance** (covered): Each invited user sees only the intended team and sites. Steps: phase-4 - **recovery** (covered): Shared credentials or excessive roles defeat team separation. Steps: phase-5 ## Sources - [xCloud agent capability boundaries](https://github.com/xCloudDev/xcloud-agent-skills/blob/main/plugins/xcloud/reference/capability-map.md) — reviewed 2026-09-30; v4.4.2 package; xCloud v2.8.8 capability review - [WordPress roles and capabilities](https://wordpress.org/documentation/article/roles-and-capabilities/) — reviewed 2026-09-30 - [WordPress plugin administration](https://wordpress.org/documentation/article/manage-plugins/) — reviewed 2026-09-30 - [Site backups in xCloud](https://xcloud.host/docs/site-backups-in-xcloud/) — reviewed 2026-09-30 - [WordPress hardening handbook](https://developer.wordpress.org/advanced-administration/security/hardening/) — reviewed 2026-09-30 - [xCloud MCP documentation and connection profiles](https://app.xcloud.host/mcp/docs) — reviewed 2026-09-30 - [xCloud team roles and permissions](https://xcloud.host/docs/team-roles-permissions-in-xcloud/) — reviewed 2026-09-30 - [Manage WordPress updates with Updates Manager](https://xcloud.host/docs/manage-wordpress-updates-with-updates-manager/) — reviewed 2026-09-30 - [Vulnerability Checker in xCloud](https://xcloud.host/docs/vulnerability-checker-in-xcloud/) — reviewed 2026-09-30 ## Continue [Explore the next WordPress workflow](https://xcloud.host/use-cases/playbooks/add-transactional-email-to-a-wordpress-site/) - [Review agency access across client teams](https://xcloud.host/use-cases/operations/review-agency-access-across-client-teams/) - [Prepare a repeatable WordPress client onboarding](https://xcloud.host/use-cases/solutions/prepare-a-repeatable-wordpress-client-onboarding/) - [Transfer WordPress access when a retainer ends](https://xcloud.host/use-cases/solutions/transfer-wordpress-access-when-a-retainer-ends/)