The platform owner is accountable for separating design intent from access policy. Presentation rules should describe how objects are managed, while authorization rules should define who can act. When those layers are mixed, ownership becomes unclear, governance weakens, and UI changes can create security regressions that are difficult to detect during review.
Why This Matters for Security Teams
When presentation rules and authorization rules live in the same workflow, accountability blurs exactly where security teams need clarity. A UI condition, label, or workflow step can start acting like an access decision, and reviewers may miss that the system has changed who can do what. That is especially risky in NHI-heavy environments, where Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
The accountable party is usually the platform owner, because that role owns the design boundary between interface behavior and enforcement logic. Security reviewers can validate policy, but they cannot compensate for a system that lets a presentation rule quietly override an authorization rule. Current guidance suggests treating those layers as separate control points, with NIST SP 800-53 Rev 5 Security and Privacy Controls used to anchor explicit access enforcement rather than UI semantics alone. In practice, many security teams discover the gap only after a harmless interface change has already widened access.
How It Works in Practice
In a clean identity workflow, presentation rules decide how an object appears, when controls are visible, and what actions a user or operator can see. Authorization rules decide whether the action is actually allowed. The accountable owner must ensure those functions stay separate, because mixing them creates a false sense of control: a button may disappear while the underlying API remains callable, or a workflow may look locked while another path still grants action authority.
Practitioners generally reduce this risk by enforcing a few boundaries:
- Keep authorization in a dedicated policy layer, not in UI logic or page state.
- Evaluate access at request time, not only at render time.
- Use explicit policy names and ownership so design intent is reviewable separately from access decisions.
- Test hidden paths, direct API calls, and alternate clients rather than relying on the interface as proof of control.
This separation aligns with the governance emphasis in Top 10 NHI Issues, where misconfiguration, over-privilege, and poor visibility repeatedly turn identity design flaws into operational incidents. It also fits the principle behind NIST SP 800-53 Rev 5 Security and Privacy Controls, which expects access control to be explicit, testable, and independent of presentation logic. These controls tend to break down in low-code platforms and workflow builders because designers can wire visuals, rules, and permissions together faster than reviewers can separate them.
Common Variations and Edge Cases
Tighter separation often increases implementation and review overhead, requiring organisations to balance clarity against delivery speed. The tradeoff is worthwhile, but there is no universal standard for how much presentation logic may reference access state. Current guidance suggests allowing presentation to reflect status, while preventing it from making the final allow or deny decision.
Edge cases appear when teams use conditional forms, wizard flows, or admin consoles that must hide sensitive options for usability reasons. Hiding an option is not the same as denying it, and the accountable owner has to prove the distinction in code and in policy tests. This becomes more important when multiple teams share one workflow, because a product team may own the interface while a security team owns the policy engine, creating ambiguity unless responsibility is explicitly assigned.
For NHI operations, the same issue often shows up in service portals that mint tokens, rotate secrets, or approve integrations. The safer pattern is to treat the portal as a presentation layer and enforce approval, issuance, and revocation through separate authorization controls. In practice, teams should validate this boundary with breach-style testing, and the 52 NHI Breaches Analysis shows how quickly small identity design mistakes become repeatable attack paths when the workflow itself is ambiguous.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Separating identity design from access enforcement reduces NHI workflow confusion. |
| NIST CSF 2.0 | PR.AC-4 | Access decisions must be explicit and independent of UI presentation. |
| NIST SP 800-63 | Identity proofing and session handling should not be conflated with UI behavior. | |
| NIST Zero Trust (SP 800-207) | AC-1 | Zero Trust requires policy evaluation at the point of access, not at render time. |
| NIST AI RMF | GOVERN | Ownership and accountability are core governance needs when controls overlap. |
Assign clear accountability for policy, design, and enforcement boundaries.
Related resources from NHI Mgmt Group
- Who is accountable when authorization rules behave differently across applications?
- Who should be accountable for access governance when enterprises use a partner to implement identity controls?
- Who should be accountable for enterprise authorization policy design and enforcement?
- Who is accountable when authentication settings, fraud controls, or identity provider connections are misconfigured in production?
