Both, but accountability starts at the tenant level. The platform may provide common tooling, yet each customer environment has its own data classes, access paths, and reporting obligations. MSPs should preserve tenant separation in governance workflows while still aggregating enough intelligence to spot repeatable exposure patterns.
Why AI Access Risk Cannot Be Managed at Just One Layer
For MSPs, AI access risk is not a single control problem. The tenant is where customer-specific data, approvals, exception handling, and reporting obligations live, but the platform still shapes the shared guardrails, logging, and inheritance model. If you only manage one side, you miss either local accountability or systemic exposure.
A tenant-level view answers who approved access, what data was exposed, and which customer is responsible for the decision. A platform-level view answers whether the same weakness, misconfiguration, or privilege pattern could affect multiple tenants at once. The right operating model has to preserve both views without collapsing them into one.
That distinction matters because AI access often crosses normal application boundaries. When the platform supplies common orchestration, agents, tokens, or tooling, a weakness in the shared layer can create repeatable exposure. At the same time, customer environments may differ in data sensitivity, retention, segregation, and escalation thresholds, so the same technical event can have different governance consequences per tenant.
Where Tenant Governance Ends and Platform Governance Begins
Tenant-level governance should own the policy decision, the business justification, and the audit trail for each customer environment. That means access approvals, scope restrictions, and exception handling should be recorded in a way that can be reviewed per tenant, not only as a platform-wide aggregate. For MSPs, this is the layer that proves accountability.
Platform-level governance should own the shared controls that no tenant can safely duplicate on its own. Shared identity patterns, default permissions, credential handling, logging, and isolation design belong here because they determine the blast radius if one workflow is abused. A platform may standardise control implementation, but it should not replace tenant-specific authorization.
Multi-tenant AI setups work best when the platform sets the secure baseline and each tenant adds its own policy overlay. That prevents the common failure mode where a strong central tool creates the illusion of complete control, while customer-specific access decisions are left undocumented or handled informally.
What MSPs Should Look For When the Same Weakness Could Hit Many Tenants
Repeatable exposure patterns are the clearest sign that the issue has become platform-level. If the same agent role, service credential, connector, or approval path is being reused across tenants, a single mistake can become a fleet-wide incident. NHIMG’s Top 10 Agentic AI Identity Issues is useful here because it focuses on overprivilege, shared credentials, and trust boundaries that commonly turn one tenant problem into many.
Platform-wide telemetry also matters because it can reveal patterns that no single tenant would see. If the same denied action, unusual token use, or policy bypass attempt appears across customers, the MSP may be seeing a control design issue rather than isolated user behaviour. That is where aggregation adds value, provided it does not erase tenant-level ownership.
In practice, the best sign that a control belongs at the platform layer is simple: one fix should reduce risk for every tenant without weakening each tenant’s ability to govern its own data and approvals. If a control cannot be applied consistently across customers, it probably needs tenant-specific enforcement, not just a shared platform rule.
Risk and Threat Considerations
AI access risk becomes materially worse when MSPs treat all tenants as one security domain. A shared control failure can expose multiple customers at once, while a tenant-specific approval failure can create compliance and accountability gaps even when the platform itself is well designed.
Failure mechanism: Reused credentials, weak isolation, or shared permission models let a compromise in one tenant or one platform component cascade into other environments. That can also obscure who authorised access, which is a problem when customer data classes and reporting duties differ by tenant.
Impact: The result can be cross-tenant exposure, broken auditability, inconsistent incident response, and a much larger remediation scope than either the MSP or the customer expected. The same design flaw may become both a security incident and a governance failure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack surface, CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI access risk here centers on tenant-scoped privilege and shared control abuse. |
| Recommendation — Separate tenant authorizations and limit shared agent privilege. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Shared AI access patterns can turn one tenant permission mistake into fleet-wide overprivilege. |
| Recommendation — Minimise shared identities and scope access per tenant. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | MSPs need tenant-specific governance and platform-wide IAM controls for shared AI access. |
| Recommendation — Enforce tenant-separated IAM and centralise control monitoring. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is central to limiting tenant and platform AI access blast radius. |
| Recommendation — Restrict AI access to the minimum privileges needed. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Tenant and platform separation depends on defined access control responsibilities. |
| Recommendation — Define and enforce access rules separately for each tenant. | ||
Practitioner Guidance
What to prioritise: Keep access decisions tenant-scoped even when the tooling is shared. The first question is always which customer owns the approval, the exception, and the evidence.
What to verify: Confirm that the platform can show tenant-by-tenant authorization, logging, and segregation without relying on a shared administrative shortcut. If it cannot, treat that as an architecture issue, not just a process gap.
What good looks like: The MSP can aggregate patterns centrally for detection and reporting, but every tenant still has a defensible record of who accessed what, why it was allowed, and how long it remained valid.
Practitioner takeaway: The safest operating model is tenant-owned accountability with platform-enforced guardrails, not a choice between the two. MSPs that collapse AI access into a single pooled control plane usually gain convenience at the expense of auditability and blast-radius control.