Tenant isolation
Tenant context should stay bounded at the gateway layer. The public site should make that separation legible before a buyer asks for architecture details.
Security
Trust starts with clear boundaries.
MSPlex connects AI to production MSP systems, which means trust cannot be implied. This page explains the public posture: tenant isolation, managed auth handling, and how to think about evaluation before implementation details move into a deeper review.
Trust pillars
The public trust posture should answer the first hard questions.
Managed auth boundaries
MSPlex is designed to keep auth handling in a managed exchange layer instead of scattering credentials across every AI client and workflow definition.
Operational review first
Security review is part of operational fit, not an afterthought added after a workflow already exists.
Public posture
What this public surface should clarify before deeper review.
What the gateway should handle
- Tool-call routing between AI clients and MSP systems.
- Tenant-aware boundaries for operational requests.
- Managed auth handling in the exchange layer.
- Structured responses returned to the workflow that requested them.
What buyers should still ask
- Which exact actions are in scope for the connectors you care about.
- How the current build lines up with your rollout timing.
- Which environment-specific security questions need a direct review.
- What the onboarding path looks like for your MSP stack.
Secrets lifecycle
The credential story should be visible, not implied.
Buyers should be able to see where credentials live, what the gateway passes forward, and which surfaces never receive secrets at all. This is the clearest public explanation of the managed boundary before a deeper review begins.
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
Security review flow
Use the public site to narrow the questions, not to replace them.
01
Identify sensitive workflows
Confirm which systems and actions matter in your environment, especially where credentials and tenant scope are most sensitive.
02
Define the trust boundary
Map how tenancy, auth, and returned data should behave before the first rollout conversation moves into implementation details.
03
Review the public proof
Use the connector and experience surfaces to understand the operational model in public-safe terms before asking for deeper detail.
04
Escalate the open questions
Bring the remaining questions into the contact flow so the evaluation can move from public posture to environment-specific review.
Review next
The strongest trust story is spread across a few public surfaces.
Review next
Practical note
Public pages should establish the trust model and answer the first questions. Deeper environment-specific detail belongs in the evaluation process, not in generic marketing copy.
Bring your security questions into the rollout conversation.
The right next step is not vague reassurance. It is a direct discussion about the systems you run, the workflows you want AI to touch, and the trust boundaries that matter in your environment.