What do teams get wrong when they add custom roles and fine-grained permissions?

Why This Matters for Security Teams

Custom roles and fine-grained permissions look precise on paper, but they often create a permission model that only the original implementers can interpret. Once teams begin inventing local role names, action-level exceptions, and one-off approval paths, access reviews become subjective and drift starts immediately. That is especially dangerous for secrets-bearing workloads and machine identities, where compromise can move faster than human review cycles. The Ultimate Guide to NHIs — Key Challenges and Risks notes how identity sprawl undermines centralized control, and the OWASP Non-Human Identity Top 10 frames over-permissioned non-human identities as a recurring failure mode. The real issue is not granularity itself, but uncontrolled taxonomy growth that breaks governance, auditability, and revocation. In practice, many security teams discover the model is unmanageable only after a recertification, incident, or customer escalation has already exposed how differently each team interpreted the same permission.

How It Works in Practice

The strongest pattern is to treat roles as a small, shared language for business intent, then push narrowly scoped actions into a controlled entitlement layer. That means a team can request billing-admin or support-operator, but cannot create its own bespoke role every time a new workflow appears. Fine-grained permissions still matter, especially for NHI and agentic workloads, but they should map to a bounded set of actions that are reviewed centrally and enforced consistently.

Operationally, that usually means three things:

• Define a stable role catalog with clear ownership, expiry, and approval rules.
• Model sensitive actions separately from broad job functions, so reviewers can see what the role actually enables.
• Use policy-as-code or entitlement checks to decide at request time whether a specific action is allowed, rather than encoding every exception into the role itself.

For non-human identities, this is especially important because access often depends on workload context, not a human job title. The DeepSeek breach is a reminder that exposed credentials and uncontrolled access paths can cascade quickly once a system is reachable. Current guidance from the OWASP Non-Human Identity Top 10 and CISA Zero Trust Maturity Model both support tighter scoping, but the practical implementation is to keep entitlement design understandable enough that humans can still review it. These controls tend to break down when every product team can define new roles without central review, because the approval model fragments faster than the policy team can normalize it.

Common Variations and Edge Cases

Tighter permission design often increases operational overhead, requiring organisations to balance precision against review burden and developer speed. That tradeoff is real, which is why current guidance suggests not every exception should be flattened into a global standard, but also not every workflow should get its own role.

Common edge cases include:

• Temporary project access that should be time-bound rather than permanently added to a custom role.
• Service accounts that need a single narrow API action, where a role is too broad and a direct allow rule is safer.
• Customer-specific admin features that should be isolated behind tenant policy, not multiplied into separate role names.
• Agentic or automated workflows that need dynamic checks at runtime because static role membership cannot predict every tool call.

In those cases, best practice is evolving toward a layered model: a small canonical role set, context-aware authorization for exceptional actions, and short-lived elevation where necessary. The State of Secrets in AppSec underscores how quickly secrecy and access problems become operational problems when governance fragments. The main exception is highly regulated environments with strict segregation-of-duties requirements, where some additional role specificity may be justified, but even there the vocabulary should stay controlled and reviewable.

Related resources from NHI Mgmt Group

• What do teams get wrong when they treat identity verification as a one-time compliance task?
• What do teams get wrong when they treat SoD as only an audit requirement?
• What do teams get wrong when they measure DSPM success?
• What do teams get wrong when they add too many OAuth scopes?