What's included
Scoped seats
Access is granted per area, per tenant: hand a customer's IT lead directory and devices, keep security and billing to yourself. A seat is a policy you define — not a stripped-down second product.
Read-only or hands-on, per area
Each area a seat can see is independently read-only or full — an IT lead who should look but not touch gets exactly that. Write level is enforced on the server: a mutating request without full access is refused, whatever the client asks for.
Their branding
Each tenant's portal carries the customer's own name and logo — their console, not a generic MSP shell with someone else's badge on it.
Server-side isolation
A customer seat can never see another customer's name, data, or existence — the tenant roster itself is filtered in the API, not hidden client-side. There is no cross-tenant scope for a customer seat to reach.
Invites and lifecycle
Invite a customer admin by email — any domain — into exactly the seat you defined. When the relationship changes, suspend the account or revoke its sessions immediately; a disabled seat is refused at sign-in.
Everything audited
Customer-seat actions land in the same per-tenant, tamper-evident audit log you already see — one hash-chained trail per customer, whoever held the keyboard. Shared responsibility without a shared blind spot.
MSP-only surfaces — the cross-tenant book view, tenant onboarding, and console administration — are never available to customer seats. The customer portal is part of early access; the seat experience is being refined with founding partners' feedback.
Give your co-managed customers a console of their own
They get a scoped, branded seat on their tenant; you keep the master view, the write gates, and one audit trail across both of you.