Who should own tenant-specific permission changes in a policy-driven model?

Why This Matters for Security Teams

Tenant-specific permission changes look like a routine delegation problem, but in a policy-driven model they define the boundary between global control and local autonomy. If the wrong team can widen access, one tenant’s exception can quietly become another tenant’s exposure. That is especially risky for non-human identities, where service accounts, API keys, and workload tokens often carry more privilege than operators expect. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks shows how frequently organisations mismanage these identities, and the OWASP Non-Human Identity Top 10 reinforces that excessive privilege and weak governance remain core failure modes.

The real issue is not who clicks approve, but who is accountable for the policy model itself. Platform and IAM teams must preserve the canonical policy foundation, while tenant administrators can only operate within clearly bounded exception paths. In practice, many security teams discover this distinction only after a tenant-specific change has expanded access beyond its intended scope, rather than through deliberate governance design.

How It Works in Practice

The cleanest operating model separates policy ownership from policy administration. Platform or IAM teams own the global rule set: the baseline roles, entitlement schema, approval workflow, and guardrails that determine what a tenant may request. Tenant administrators then manage only the scoped exceptions allowed by that framework, such as adding a specific workload to a permitted role set, enabling a named integration, or requesting a time-bound override.

This approach works best when policy is expressed as code and evaluated at request time, not embedded as static spreadsheet logic. Current guidance from NIST Cybersecurity Framework 2.0 supports clear governance, auditable change control, and repeatable access management. For NHI environments, NHI Mgmt Group recommends pairing that governance with lifecycle discipline from the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs so permission changes remain traceable across approval, implementation, and revocation.

• Platform/IAM teams define the tenant permission template, allowed fields, and maximum privilege boundaries.
• Tenant admins submit changes only through approved workflows, with the system constraining them to pre-authorised scopes.
• All changes should be logged with requester, approver, tenant, effective time, and expiry where applicable.
• High-risk exceptions need separation of duties so the same operator cannot request, approve, and implement the change.

This model also reduces drift when tenants are numerous or fast-moving, because the policy foundation stays consistent even as local needs vary. These controls tend to break down when tenants are allowed to edit the underlying policy schema directly, because local convenience quickly turns into global privilege creep.

Common Variations and Edge Cases

Tighter central control often increases operational friction, requiring organisations to balance tenant agility against governance consistency. In mature environments, that tradeoff is usually worth it for baseline permissions, but there is no universal standard for how much exception authority tenants should receive. Best practice is evolving toward narrow delegation, short-lived approvals, and periodic recertification rather than broad standing admin rights.

One common edge case is delegated administration for subsidiaries, resellers, or managed service tenants. In those models, tenant admins may need broader control inside their own boundary, but platform teams should still own the permission framework, the approval thresholds, and the emergency rollback path. That distinction matters because a tenant can be autonomous without being sovereign.

Another exception is temporary access during incident response or onboarding. Those changes should be treated as time-bound overrides with explicit expiry and post-event review, not as permanent adjustments. The NHI Mgmt Group note that only a small share of organisations have mature offboarding and revocation processes makes this especially important, since permission exceptions often outlive the original use case if ownership is unclear. For broader risk framing, the Top 10 NHI Issues highlights how excess privilege and weak lifecycle controls compound each other over time.

Related resources from NHI Mgmt Group

• Who should own ingress policy in a Kubernetes environment?
• Who is accountable for AI policy violations when the judge model is wrong?
• How does the consumer-secret-entitlement model help with governance at scale?
• Who should own tenant-level SSO and MFA policy?