Notifications
Clear all
Topic starter
09/07/2026 12:35 pm
TL;DR: PBAC evaluates persona, context, and intent at request time, with research cited in the article showing revocation and notification can happen in tens of milliseconds, while indirect prompt-injection studies still found broad leakage risk across LLM systems. The governance issue is not latency, but whether identity controls actually constrain what AI assistants reveal when answers are generated.
NHIMG editorial — based on content published by Knostic: Key Findings on Persona-based Access Control (PBAC) Software
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
Questions worth separating out
Q: How should security teams implement PBAC for AI assistants and enterprise search?
A: Start by placing the policy decision at answer time, not only at login or source retrieval.
Q: Why do AI copilots create access risks that standard IAM policies miss?
A: Standard IAM can prove that a user reached a source, but it does not always control what the AI layer assembles from that source.
Q: What breaks when persona and purpose are not checked before AI output is shown?
A: The system can return data that the requester could legitimately reach in a source system but should not see in the generated answer.
Practitioner guidance
- Define answer-time policy boundaries Map which copilots, enterprise search tools, and RAG pipelines must evaluate persona and purpose before any response is shown.
- Separate source entitlement from response entitlement Review where users are allowed to read a source and where they are allowed to see an AI-generated synthesis of that source.
- Require decision logs for every AI access decision Retain the evaluated persona, context, purpose, and policy outcome so security, audit, and privacy teams can explain why an answer was released or blocked.
What's in the full article
Knostic's full article covers the operational detail this post intentionally leaves for the source:
- Benchmarks and latency claims for runtime policy decisions in AI-assisted workflows.
- Comparative discussion of PBAC tooling categories across enterprise search and copilots.
- Examples of how persona and purpose can be encoded into access policy models.
- Tool-by-tool implementation notes for organisations moving from concept to deployment.
👉 Read Knostic's analysis of persona-based access control for AI answers →
Persona-based access control for AI responses: what teams need to know?
Explore further
09/07/2026 12:39 pm
PBAC is becoming an answer-layer control, not just an authorization concept. Traditional IAM decides whether a principal can enter a system, but AI assistants also need a decision on what may be revealed after retrieval. That shifts governance from access alone to disclosure control, which is the more relevant question for copilots, search, and LLM workflows. The practitioner conclusion is that authorization now has to extend to the response itself.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why answer-time governance often fails before teams can even establish the identity baseline.
A question worth separating out:
Q: How do security teams know if PBAC is actually reducing oversharing?
A: Look for three signals: fewer sensitive-answer incidents, consistent policy decisions across similar prompts, and complete decision logs showing the evaluated persona, context, and purpose. If the same request produces different outcomes without a documented reason, the policy model is too loose or the attributes are too ambiguous.
👉 Read our full editorial: Persona-based access control for AI answers and oversharing risk
