Notifications
Clear all
Topic starter
09/07/2026 12:37 pm
TL;DR: Persona-based access control ties access to functional intent, behavior, and context in real time, positioning it as a practical bridge between RBAC simplicity and ABAC flexibility, according to Knostic. For IAM and governance teams, the shift matters because access decisions increasingly need to reflect purpose, not just identity or attributes.
NHIMG editorial — based on content published by Knostic: Key Findings on PBAC and persona-based access control
Questions worth separating out
Q: How should security teams implement persona-based access control in an IAM programme?
A: Start with a small set of high-value personas built around recurring business intent, not job titles alone.
Q: Why do traditional RBAC and ABAC models struggle in AI-assisted knowledge environments?
A: RBAC is too static for changing context, while ABAC can become too complex when many attributes and exceptions accumulate.
Q: What breaks when persona definitions are too broad or too many personas are created?
A: Broad personas turn into hidden overpermission, because the policy no longer reflects a meaningful business purpose.
Practitioner guidance
- Map recurring work patterns into personas before expanding role structures Run persona workshops with business owners, then group repeated access needs by intent, task type, and risk context.
- Align persona policy with data classification and AI output boundaries Connect each persona to specific sensitivity labels, allowed sources, and prohibited output types so the policy applies both to documents and to synthesized AI responses.
- Test access decisions with realistic prompts and context changes Simulate common user requests from managed devices, unmanaged devices, approved locations, and off-hours sessions.
What's in the full article
Knostic's full article covers the operational detail this post intentionally leaves for the source:
- Persona workshop structure for mapping functional intent into reusable access profiles
- Policy testing examples for Copilot and Glean style AI search workflows
- Data classification alignment steps for contractor, finance, and support personas
- Implementation guidance for integrating persona logic with existing IAM platforms
👉 Read Knostic's analysis of persona-based access control for AI workflows →
Persona-based access control: what it means for IAM teams?
Explore further
09/07/2026 12:43 pm
PBAC is best understood as an access governance model for intent, not just identity. Static role assignment assumes the requester’s purpose is already known and stable, which is increasingly false in hybrid work and AI-assisted search. By tying permissions to declared purpose and context, PBAC shifts the governance question from who the user is to what the user is trying to do. Practitioners should treat that as a change in authorization philosophy, not a cosmetic policy tweak.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
A question worth separating out:
Q: How do organisations know whether persona-based access control is actually working?
A: Look for fewer ad hoc exceptions, clearer audit logs, and fewer cases where AI or users can infer information outside their intended purpose. If policy decisions can be explained by persona, context, and data sensitivity, the model is working. If teams still rely on manual overrides, the governance design is not yet mature.
👉 Read our full editorial: Persona-based access control redefines access for AI-driven workflows
