Identity governance best practices for LLMs and generative AI

At a glance

What this is: RSA Security argues that LLMs and generative AI introduce new data governance risks that identity governance and administration controls are meant to absorb.

Why it matters: This matters because IAM, NHI, and human access programmes now have to govern assistant-driven data access, not just user and service-account access.

By the numbers:

• 65% of organisations have experienced at least one cybersecurity incident which occurred because of the use of AI agents.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).

👉 Read RSA Security's guidance on identity governance best practices for LLMs

Context

Generative AI changes the data governance problem because assistants can ingest, surface, and sometimes redistribute information through interfaces that look conversational but behave like access paths. In identity terms, that means the issue is not only who can log in, but what a user, machine account, or assistant can see, reuse, and disclose once access has been granted.

RSA Security frames this around identity governance and administration because regular access reviews, approval workflows, and data-owner oversight are still the main control layer for determining whether data access is appropriate. The gap is that AI-assisted access can blur the boundary between legitimate retrieval and unintended disclosure, especially when the assistant is configured too broadly.

For teams building NHI and human identity programmes together, the practical question is whether current governance assumes access is static enough to review after the fact. When the system can answer across multiple data stores or assistant instances, that assumption weakens quickly.

Key questions

Q: How should security teams govern LLM access to organisational data?

A: Security teams should treat LLM access like any other entitlement. Define which data sources the assistant may query, which users may invoke it, and which outputs are prohibited. Then test those rules with real prompts and include the assistant in access certification so owners can revoke access when the business case no longer exists.

Q: Why do generative AI tools create identity governance risk?

A: Generative AI tools create identity governance risk because they can broaden the practical use of existing entitlements. A user may remain authorised to access a system, but the assistant can combine that access across repositories, expose sensitive content in a new format, or return material that the original requester should not see.

Q: What do teams get wrong about AI assistant permissions?

A: Teams often assume that if a user is allowed to access a source system, the assistant can safely access everything behind that system as well. That is the wrong model. Assistant permissions need separate scoping, because broad connectors can turn a legitimate query into unintended disclosure across users, departments, or data classes.

Q: How can organisations tell whether assistant governance is working?

A: Assistant governance is working when owners can explain what the assistant may access, when certification records show those permissions were reviewed, and when leakage tests fail cleanly instead of exposing other users’ data. If the assistant can answer from restricted sources, governance is not operating effectively.

Technical breakdown

Why LLMs turn data access into a governance problem

LLMs and digital assistants do not create risk simply by existing. They create risk when they are allowed to ingest user input, query organisational data, and produce outputs that may expose content beyond the original request. In practice, the governance problem is less about model internals and more about entitlement scope, data partitioning, and how much trust is placed in the assistant to decide what is relevant. If the assistant can see too much, it can reveal too much. That makes access boundaries, approval logic, and data-owner controls central to safe deployment.

Practical implication: define assistant data boundaries before deployment and test them against real user prompts and real repositories.

How IGA controls support generative AI oversight

Identity governance and administration extends into AI because it already handles access reviews, certifications, and approval workflows across users, machines, and resources. For generative AI, IGA helps answer whether the right account has the right access to the right data, and whether that access still makes sense after the assistant is rolled out. The core control pattern is not model training oversight alone. It is ongoing entitlement governance, supported by audit evidence that shows who approved access, what data was exposed, and when exceptions were made.

Practical implication: include AI assistants in regular access review and certification cycles, with explicit review of repository and connector permissions.

Deterministic versus non-deterministic AI in security operations

RSA Security distinguishes between non-deterministic generative models and deterministic risk models used in authentication. That distinction matters because security operations need outputs that can be explained, repeated, and tied to policy. A black-box assistant may be acceptable for productivity tasks, but it is harder to justify as the basis for access decisions or sensitive data handling without strong guardrails. In identity programmes, the safer pattern is to keep decision points deterministic wherever possible and reserve generative tools for constrained assistance rather than autonomous access judgment.

Practical implication: avoid using unconstrained generative AI as the decision engine for access or identity governance controls.

NHI Mgmt Group analysis

LLM governance fails first at the boundary between retrieval and disclosure: the central problem is not that assistants can answer questions, but that they can be configured with broader access than the user actually needs. Once that boundary is loose, identity governance stops being a matter of who is entitled and becomes a matter of what the assistant is allowed to surface. The implication is that access scope must be treated as an output-control problem, not only an input-control problem.

Identity governance is now the control plane for AI-assisted data use: regular access reviews, certifications, and approval workflows remain the only scalable way to show that assistant access is still justified. That is especially true when multiple copilots or assistant instances exist across the estate. Practitioners should view AI exposure through the same governance lens as privileged access, because the business risk is created by overbroad entitlement, not by model branding.

Data partitioning is the named concept that most organisations still under-estimate: if User X can receive responses based on User Y’s files, the programme has a partitioning failure, not just a configuration issue. This is where identity governance, entitlements, and information architecture intersect. The practical conclusion is that assistant rollout must be blocked until cross-user and cross-domain data leakage tests are part of acceptance criteria.

Generative AI should not be used as an implicit access authority: if a system can decide what to retrieve and what to return without human policy limits, governance assumptions begin to collapse. That is why security teams need explicit policy around allowed inputs, allowed sources, and allowed outputs. The implication for the field is that AI control design belongs inside identity governance, not outside it.

Deterministic risk decisions and generative assistance solve different problems: risk-based authentication can safely automate step-up decisions because it is designed to evaluate signals consistently, while LLMs are better treated as constrained assistants. Conflating the two creates false confidence in explainability and control. Practitioners should keep identity decisions deterministic and use generative tools only where their outputs do not directly govern access.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That gap makes OWASP Agentic AI Top 10 a useful forward reference for teams extending governance into assistant behaviour.

What this signals

Data partitioning debt: the fastest way for assistant risk to become enterprise risk is to let repository breadth outrun governance review. With 80% of organisations already reporting agents acting beyond intended scope, the programme signal is clear: entitlement sprawl is now an AI control issue, not just an access management issue.

The next maturity step is to treat assistants as governed access surfaces, not just productivity tools. That means linking certification, logging, and repository scoping to the same control objectives used for privileged access and workload identity, then validating those controls against leakage scenarios before expansion.

Teams that are already formalising AI governance should align the operating model with NIST Cybersecurity Framework 2.0 and, where generative AI is in scope, NIST AI 600-1 Generative AI Profile so ownership, monitoring, and response are tied to identity rather than experimentation.

For practitioners

• Define assistant data boundaries Write explicit rules for what users can input, what the assistant can query, and what it may return. Validate those rules against sensitive repositories, cross-user data separation, and outbound channels before broad rollout.
• Add AI assistants to access reviews Include every assistant, copilot, and connector in scheduled certification workflows so data owners can approve or revoke access to repositories, mailboxes, and file stores with the same discipline used for other entitlements.
• Test for cross-user leakage Run negative tests that try to make the assistant answer from another user’s files or restricted datasets. Fail deployment if the system can retrieve or summarise content outside the requester’s scope.
• Separate assistance from authority Keep access decisions, step-up rules, and sensitive-data handling deterministic. Use generative tools for constrained assistance, but do not let them function as the policy engine for identity or entitlement decisions.

Key takeaways

• Generative AI becomes an identity governance problem when assistants can retrieve and disclose data beyond the original user context.
• AI assistant misuse is already widespread, with 80% of organisations reporting behaviour beyond intended scope and 52% lacking full audit visibility.
• The strongest control pattern is to separate deterministic access decisions from generative assistance and put assistant permissions into regular certification cycles.

Key terms

• Assistant Data Boundary: The set of sources, records, and output channels an AI assistant is allowed to access and use. In identity governance terms, this boundary defines where a legitimate entitlement ends and harmful disclosure begins, and it must be validated before deployment rather than assumed from user access alone.
• Data Partitioning: The practice of separating one user’s or tenant’s data from another’s so that retrieval and response generation cannot cross authorised boundaries. For AI assistants, partitioning is a governance control as much as an architecture pattern, because weak partitioning turns broad access into unintended exposure.
• Deterministic Risk Model: A security model that produces repeatable, explainable outcomes from defined signals and rules. In identity programmes, deterministic models are better suited to access decisions than unconstrained generative systems because practitioners can validate why a step-up challenge or approval was triggered.
• Access Certification: A formal review process where data owners confirm whether an account, role, or system still needs its current access. For AI assistants and other NHIs, certification must cover connectors, repository permissions, and any other entitlement that expands what the system can retrieve or disclose.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by RSA Security: Identity Governance & Administration Best Practices for LLMs and Generative AI. Read the original.