Client-level permissions are access controls that separate one customer environment from another inside an MSP platform. They limit what users, teams, and administrators can see or change for each tenant, which reduces accidental exposure, supports least privilege, and helps preserve operational boundaries as the MSP scales.
Expanded Definition
Client-level permissions are a tenant-scoped access model used in MSP platforms to decide who can view, manage, or administer a specific customer environment. They are distinct from broad administrative roles because the control boundary is the client, not just the tool. In NHI operations, this matters when human operators, automation, and service accounts interact with multiple customer tenants through shared consoles, APIs, and orchestration layers.
Definitions vary across vendors, but the security objective is consistent: limit exposure so a mistake or compromise in one tenant does not cascade into another. That makes client-level permissions a practical expression of least privilege, separation of duties, and Zero Trust Architecture principles as described in the OWASP Non-Human Identity Top 10 and the access control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls. In MSP environments, this usually applies to dashboards, ticketing integrations, backup tooling, remote management, and NHI-driven workflows that can touch many tenants at once.
The most common misapplication is treating a global admin role as sufficient tenant protection, which occurs when client scoping is assumed to exist because the platform has role names but no enforced per-client boundaries.
Examples and Use Cases
Implementing client-level permissions rigorously often introduces operational friction, requiring organisations to weigh faster cross-tenant support against the risk of overexposure and accidental lateral access.
- A service desk technician can reset credentials for Client A but cannot view billing, logs, or backups for Client B, reducing unnecessary tenant visibility.
- An automation service account is scoped to a single customer’s endpoint fleet, so an integration failure cannot push changes across all managed tenants.
- A senior engineer may have read-only access to multiple tenants for incident response, while write access stays with a smaller admin group to preserve separation of duties.
- A backup operator can restore data for one client only after explicit approval, aligning tenant boundaries with change-control requirements and auditability.
- Tenant-scoped access reviews are paired with NHI governance so API keys, certificates, and service accounts are reassigned or revoked when a client contract changes, a pattern reinforced by the Ultimate Guide to NHIs — Key Challenges and Risks and the operational failures seen in the Microsoft SAS Key Breach.
Why It Matters in NHI Security
Client-level permissions are a control point for blast-radius reduction in MSPs, where a single identity, token, or operator mistake can cross tenant boundaries. This is especially important because NHIs often outnumber human identities by 25x to 50x, and 97% carry excessive privileges according to NHI Mgmt Group. When those identities are tied to shared tooling, permission mistakes become tenant isolation failures rather than routine access issues.
Good client scoping supports compliance evidence, incident containment, and safer automation. It also reduces the chance that a compromised console, script, or API key can expose multiple customer environments at once, a pattern echoed in the Replit AI Tool Database Deletion incident and the Gemini CLI Breach. In practice, client-level permissions should be reviewed alongside OWASP Non-Human Identity Top 10 controls and mapped to tenant-aware access rules in NIST SP 800-53 Rev 5 Security and Privacy Controls.
Organisations typically encounter tenant-wide exposure only after a support escalation, compromised admin session, or misrouted automation run reveals that client separation was weaker than assumed, at which point client-level permissions become operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Tenant-scoped permissions limit excessive access across NHIs and shared admin workflows. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should enforce least privilege and separation of duties by tenant. |
| NIST Zero Trust (SP 800-207) | JIT | Zero Trust favors narrowly scoped, just-in-time access instead of broad MSP privileges. |
| NIST SP 800-63 | AAL2 | Strong identity assurance supports reliable enforcement of client-level access decisions. |
| OWASP Agentic AI Top 10 | AGENT-07 | Agentic tools must be constrained to prevent cross-tenant actions through shared permissions. |
Require higher assurance for privileged tenant operations and validate operator identity before elevation.
Related resources from NHI Mgmt Group
- What is the difference between application RBAC and function-level permissions for MCP?
- What breaks when identity controls stop at table-level permissions?
- Who is accountable when an MCP client exposes data through overbroad permissions?
- Why do page-level permissions matter for Notion-connected applications?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
