Team administration
Tenant admins can invite users, assign role bindings, manage customer-scoped access, reset MFA, and review session history from the portal.
Features
Administrative control, enforced by the gateway.
MSPlex is more than connector coverage. The platform gives MSP operators tenant-scoped administration, customer-bound access control, shown-once machine credentials, audited secret handling, approval-gated risky actions, and connector exposure that only happens after readiness checks pass.
At a glance
The features that matter before you let AI touch production.
This page focuses on the controls that shape real operator trust: who can act, how machine identities work, where secrets live, how approvals gate risky execution, and when connector tools are actually exposed to the gateway.
Machine credentials
Service accounts and API credentials are created in the tenant boundary, shown once, rotatable, revocable, and exchanged for short-lived runtime tokens.
Runtime enforcement
Tool visibility and execution both clear identity, context, entitlement, connector-readiness, quota, policy, and approval gates before dispatch.
Team access
Tenant and customer access is role-bound, not guessed at runtime.
MSPlex v1 uses a fixed baseline role catalog with tenant-wide and customer-scoped role bindings. That means predictable access control for your team without pretending there is already a custom permission-matrix builder behind the scenes.
tenant_ownerTenant-wide
Full tenant settings, billing visibility, audit access, identity management, customer management, and API credential administration.
tenant_adminTenant-wide
Connector, customer, user, service-account, and audit-management surfaces without owner-only tenant settings.
tenant_billing_adminTenant-wide
Billing and subscription visibility without connector, identity, or tenant-settings administration rights.
tenant_operatorTenant-wide
Dashboard, catalog, connection and status views, connector setup, and notification surfaces for daily operations.
tenant_auditorTenant-wide
Read-only dashboard, catalog, connection-status, audit, analytics, and notification visibility with no mutating admin actions.
customer_operator / customer_viewerBound customers only
Customer-scoped roles limit access to the assigned customer set for sub-user management, usage, connector views, and audit visibility.
Admin surface
User administration
- List tenant users with role, status, last login, and MFA enrollment
- Invite users and assign initial roles
- Change role bindings and disable or re-enable accounts
- Unlock users, review session history, and reset MFA enrollment
Admin surface
Service accounts
- Create tenant-scoped service accounts with shown-once secret material
- Rotate the secret, invalidate the previous one, and record the event
- Assign runtime roles and review last-used and tool-usage metadata
- Disable or re-enable service accounts without deleting their history
Admin surface
API credentials
- Generate machine credentials for token exchange and show them once
- Rotate or revoke credentials immediately
- Define tool or connector-category scopes
- Set optional expiry and warn operators to store the secret securely
Machine identities
Service accounts are first-class identities, not hidden API keys.
In v1, non-human automation runs through service accounts. Those identities stay tenant-scoped, can be narrowed to one or more customers, and exchange their shown-once secret for short-lived runtime tokens rather than holding long-lived access tokens.
Short-lived access tokens
Human and operator access tokens are limited to 15 minutes maximum. Service-account access tokens are limited to 60 minutes maximum, with a default target of 15 minutes.
Fresh MFA for sensitive changes
Creating or rotating a service account, changing roles, disabling principals, or altering tenant security state requires recent MFA within the last 15 minutes.
Immediate revocation path
After disablement or secret rotation, no new tokens may be minted and existing access tokens must stop being accepted within five minutes maximum.
Secret handling
Connector secrets are hidden after entry and rotated through the secret boundary.
The portal collects credentials once, the backend stores them encrypted, the UI never reveals them again, and runtime workers resolve them just in time through a secrets broker instead of carrying raw secrets through general dispatch payloads.
Opaque credential reference waiting for execution
🔐
01Secret boundary
Vendor credentials stay encrypted at rest until the gateway needs them.
📦
02Gateway dispatch
The request carries only a credential reference, not the secret itself.
🔑
03Secrets broker
A broker retrieves the secret just in time and scopes it to the tenant making the call.
⚡
04Vendor API call
The connector uses the secret in process memory only while the vendor request is in flight.
✓
05Secret disposed
The execution window closes and the secret does not persist in the worker after the call completes.
Secrets never touch
✕Logs✕Env vars✕Queue payloads✕Git repos
Storage rule
Shown once, never retrieved
Connector credentials and API secrets are displayed only at creation or rotation time. After that, the portal shows masked state like credential presence or last-updated time, not the secret itself.
Rotation model
Quarterly encryption-key rotation
Connector credential encryption keys are rotated on a scheduled cadence or through emergency re-keying, with batch re-encryption designed to avoid blocking connector operations.
Audit trail
Every secret read is logged
Secret-boundary access is logged with timestamp, actor, action, resource, and result, and unauthorized access attempts trigger alerts immediately.
Gateway enforcement
The gateway clears the request before any connector worker sees it.
MSPlex keeps policy and authorization as a platform boundary. Connector code does not invent its own access model. The same checks that govern tools/call also filter tools/list, so operators only see tools they are actually allowed to invoke.
POST /mcp -> tools/call
Identity
1Auth
Authenticate principal
2Tenant
Resolve tenant context
3Customer
Resolve customer context
Entitlements
4Snapshot
Load entitlement snapshot
5Subscription
Verify subscription status
6Connector
Verify connector entitlement
7Readiness
Verify instance readiness
Policy
8Policy
Evaluate tool policy and RBAC
9Quota
Check quota and overage
10Approval
Check approval requirement
Execution
11Dispatch
Dispatch to worker
12Audit
Write audit and metering
13Response
Return response
Policy boundary
Roles, scopes, quotas, and customer context
- Role bindings come from trusted platform state, not JWT claims alone.
- Customer context is validated only after tenant context is fixed.
- Customer-bound connector instances must match the same customer context.
- Entitlement status can force read-only or fully suspended execution.
Approval gate
Single-use approvals for risky operations
- All destructive tools require approval before dispatch.
- Approvals are single-use and expire rather than staying open forever.
- Destructive self-approval is blocked by the platform.
- Default approver role is tenant admin or tenant owner for tenant-scoped requests.
Connector operations
Connectors are exposed only after entitlement, validation, health, and activation line up.
A purchased connector is not automatically runnable. MSPlex treats connector exposure as the result of several state checks: entitlement, configuration, health, and activation. That keeps unconfigured or broken instances from silently surfacing tools.
01
Entitlement gate
The portal checks the tenant's entitlement snapshot before setup begins. Non-entitled connectors are blocked server-side before any credentials are collected.
02
Configuration and validation
Connector-specific settings are collected, credentials are sent only over HTTPS in the request body, and validation failures block instance creation until corrected.
03
Secret-boundary storage
Credential material is stored through the platform secret boundary and referenced by `credential_ref`, not copied into general worker payloads or environment variables.
04
Health and activation
Health checks run after validation. Tools are exposed only after the instance is entitled, configured, healthy enough, and explicitly active.
Entitlement state
not_entitledentitledsuspended
Configuration state
not_startedin_progressconfiguredinvalid
Health state
unknownhealthydegradedbroken
Activation state
inactiveactivedisabled
Audit and notifications
Every consequential action leaves an operator trail.
MSPlex keeps user changes, service-account rotation, connector lifecycle events, policy denials, approval decisions, and secret access attributable. The notification center then surfaces the warnings operators need to act on.
Audit coverage
- Identity events: user creation, role changes, MFA resets, session termination
- Resource events: connector creation, configuration, deletion, and health changes
- Policy events: approval granted or denied, policy and override application
- Actionable filtering by actor, resource, date range, outcome, and customer scope
Notification center
- Billing and quota alerts
- Connector health and credential-rotation recommendations
- Approval lifecycle notifications
- System notices such as maintenance windows and new connector availability
Tenant and customer isolation
- Tenant context is derived from the authenticated principal, never caller-supplied form data or route hints.
- Cross-tenant access attempts are blocked and logged as security events.
- Customer context can only narrow scope inside an already-resolved tenant boundary.
Review the feature set against your real operating model.
If your MSP needs tenant-safe AI access, machine credentials, approval gates, and connector administration in one control plane, MSPlex is built to have that conversation in concrete terms.