A managed service provider has a different problem from a single company: many clients, one team, and a hard requirement that nobody sees the wrong data. Safeguard documents the building blocks for separation. This post shows how to use them and what to check first.
What it is
Safeguard's access model is a hierarchy: Organization, then Team, then Project, then Asset. The organization is the top tenant boundary, where billing, SSO, the audit log and compliance configuration live. A team is a group of users with shared access. A project is a unit of ownership, often one per service or repository. Assets are the concrete things: repositories, images, SBOMs, vendors and workloads.
A user can belong to several teams and hold a different role in each. Roles can be scoped to a team or the whole organization.
How to use it
Map clients to the hierarchy
The docs do not prescribe an MSP layout, so choose one and confirm it with Safeguard. A common reading is one team per client inside your organization, with projects per client application. The alternative is a separate organization per client. The trade off is audit and billing boundaries against the convenience of one place. Ask Safeguard which model fits your commercial arrangement before you onboard the first client.
Use roles to limit what staff can do
Built in roles include Owner, Admin, Security Lead, Security Engineer, Developer, Auditor and Viewer. Give analysts Security Engineer scoped to the client team, so they can triage and remediate but not change policy. Give client contacts Viewer or Auditor. Auditor is read only across audit records, findings and compliance evidence.
Enterprise tenants can require SSO and SCIM provisioning, so offboarding one of your staff removes access everywhere at once. Deprovisioning revokes active sessions immediately.
Scan inside the client's network
Where a client will not open their network or share repository access, use the runner. It is part of the CLI. It polls the platform for jobs, runs each locally, and uploads only the SBOM and findings. All traffic is outbound HTTPS. Headless mode suits a server on the client's side:
safeguard runner start --workspace ./path/to/repo
safeguard runner status
Tenant admins can switch off runners and other client types, so settle that with the client admin.
Report and show posture
For each client, the compliance reports flow covers pre built and custom reports for a chosen framework and date range. If the Trust Center is switched on, each organization can publish its own page at its own slug. Restricted documents go out only through approved access requests, which keeps an audit trail.
Keep your own tooling in line
If your analysts use assistants, connect them over MCP at mcp.safeguard.sh with OAuth so each assistant acts as the signed in analyst and respects their role. An MCP key acts as the member who created it across the whole workspace, so for an MSP, prefer OAuth and keep keys out of shared scripts.
What to confirm before you commit
The docs do not describe a dedicated multi client MSP console, white labelling or cross client rollups. Confirm those with Safeguard rather than assuming them. Also confirm region: tenancy for US, EU or government is fixed at signup and cannot be moved without a migration engagement.
Try it yourself
Draw your client list as a hierarchy on one page. For each client, write the three roles that need access and the one person who may approve exceptions. If any box does not map cleanly to Organization, Team and Project, that is your question for Safeguard.
Click through it at your own pace, or open it full screen.
Quick check
What is the top level boundary in Safeguard's hierarchy?
The organization. Billing, SSO, the audit log and compliance configuration live there.
Does the runner need inbound network access at the client site?
No. It only makes outbound HTTPS connections.
Can a tenant's region be changed after signup?
Not as a self service action. It requires a data migration engagement.
