Independent analysis by NHI Mgmt GroupSource article: RSA Security, “Best Practices for LLMs and Generative AI” (January 28, 2026)

TL;DR: LLMs and AI assistants expand data exposure because prompts, entitlements, and outbound channels can all move sensitive information beyond intended boundaries, according to RSA Security. The real issue is not model novelty but governance drift: access reviews, data scoping, and control settings were built for predictable access patterns, not wide-open assistant behaviour.


At a glance

What this is: NHI Mgmt Group's analysis, drawing on RSA Security's blog post: LLMs and generative AI create data-governance risk when prompts, assistant entitlements, and outbound channels exceed intended access boundaries.

Why it matters: It matters because IAM, IGA, and PAM teams need to govern both human and non-human access paths when AI tools can surface, move, or retain sensitive data.


Context

LLMs and generative AI create an identity governance problem as much as a data problem. When a user prompts an assistant, the request can touch multiple entitlements, datasets, and outbound channels that were not designed to be assessed together.

The article frames the issue for financial services, government agencies, and high-assurance organisations that already rely on access reviews and approval workflows. Those controls remain necessary, but they were built for more predictable access patterns than assistant-driven data retrieval and response generation.

The core question is not whether AI is useful. It is whether governance can still answer who can see what, when that access is active, and what the assistant is allowed to return or transmit.


Key questions

Q: What breaks when AI agents are given broad enterprise access without tight governance?

A: Broad access turns AI agents into high-speed execution paths that can move data, spend money, modify records, or delete assets before operators can intervene. The failure is not only misuse by an attacker. The system itself can exceed intended scope during normal task completion, so the real control problem is bounding authority before runtime action begins.

Q: Why do AI assistants increase data-exposure risk even when users follow prompt rules?

A: Because prompt discipline only addresses input, while the larger risk comes from what the system is allowed to retrieve and emit. If the assistant can query multiple sources or broadcast through outbound channels, sensitive information can move beyond intended boundaries even when the user acted properly. Governance has to limit both reading and returning data.

Q: How should security teams use AI agents for user access reviews?

A: Use AI agents to gather evidence and draft recommendations, but keep final approval with accountable human reviewers until the control is proven stable. The agent should have least-privilege read access, full activity logging, and a clear escalation path for exceptions. That keeps automation useful without turning review logic into an opaque authority.

Q: What is the difference between prompt controls and data-scope controls for LLMs?

A: Prompt controls govern what a user may ask, while data-scope controls govern what the assistant can actually access and return. Both matter, but only data-scope controls stop an authorised prompt from producing an unauthorised disclosure. In practice, the second control is the one that limits blast radius.


Technical breakdown

How LLM prompt access changes the data boundary

An LLM prompt is not just an input string. In enterprise use, it can become a retrieval request, a policy evaluation, and a content-generation trigger that draws on data the user may not directly realise is in scope. That creates an access boundary problem: the assistant may have broader visibility than the human who typed the prompt, especially when connectors, indexed repositories, or workspace permissions are involved. Identity governance has to track the user, the assistant, and the dataset relationship at the same time, because the effective access decision is no longer made at a single point in the workflow.

Practical implication: treat assistant prompts as access events that must be governed against the same data-scoping rules as other entitlement-driven requests.

Why access reviews struggle with AI assistant behaviour

Traditional access reviews assume permissions remain stable long enough to be certified and then recertified. AI assistants complicate that assumption because the same account can access different sources, produce different outputs, and expose different data paths depending on context, configuration, and outbound integrations. The review control still exists, but it is now observing a moving target. That is why the article centres IGA as the basis for data protection: without visibility into current entitlements and assistant permissions, reviewers cannot reliably say whether access is appropriate or excessive.

Practical implication: include AI assistant entitlements and connected data sources in access certification scopes, not just the underlying human account.

How outbound channels turn an assistant into a data egress path

The article points to a less visible risk than prompt leakage: the assistant may broadcast information through whatever outbound channel it can reach. That means data loss can occur even when the input was legitimate and the prompt appeared well intentioned. From an identity perspective, the issue is not simply authorisation to read data, but authorisation to return or relay it. This is where governance, data classification, and application-level control intersect. If response scope is not constrained, the assistant can become an unintended relay for sensitive material.

Practical implication: govern what assistants are allowed to return, not only what they are allowed to query.


Threat narrative

Attacker objective: The objective is to extract sensitive information through a trusted assistant path that bypasses normal expectations about who can see or transmit data.

  1. Entry occurs when a user submits a prompt to a generative AI assistant that is connected to enterprise data sources or workplace content.
  2. Credential and entitlement scope determine which repositories, messages, or records the assistant can query and synthesise into a response.
  3. Impact follows when the assistant returns, relays, or retains sensitive information beyond the user’s intended or authorised boundary.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

LLM governance is fundamentally an access boundary problem. The article’s real message is that identity governance has moved upstream from user access to assistant-mediated access paths. Once prompts can trigger retrieval across connected data sources, the control question becomes whether the assistant is authorised to combine and return those sources at all. Practitioners should treat assistant scope as part of the entitlement model, not as a separate AI issue.

Access review processes assume stable permissions, and that assumption weakens under AI assistants. Traditional certification cycles were built to review relatively durable entitlements tied to people, roles, or systems. Assistant behaviour is more contextual, so the effective data surface can change with configuration, connectors, and outbound channels. The implication is that governance has to move from periodic confirmation to continuous visibility over what the assistant can reach now.

Data exposure through AI is not only an input problem. The article usefully separates user prompts from what the assistant can return or broadcast. That distinction matters because organisations often focus on what employees may type, while ignoring what the system may emit once it has access. In practice, the governance gap is response scope, not just prompt discipline.

Identity and access management now has to include AI-mediated disclosure paths. This is where human IAM, NHI governance, and application control meet. The same enterprise that certifies user access also has to understand whether an assistant is effectively operating as a non-human identity with broad retrieval and disclosure rights. That makes lifecycle, visibility, and data-owner approval problems inseparable.

Governance drift is the sharper risk than model novelty. The article is strongest when it shows that the controls failed because they were designed for predictable access patterns, not open-ended assistant behaviour. That is the named concept practitioners should carry forward: assistant governance drift. If access, return, and retention rules are not aligned, the organisation will keep certifying a control model that no longer matches how information actually moves.

From our research library:

What this signals

Assistant governance drift: organisations now have to manage the gap between what a user is allowed to ask and what an assistant is allowed to reveal. That gap widens whenever connectors, workspace permissions, and response channels are governed separately instead of as one disclosure path.

Identity governance teams should expect AI tools to expose weaknesses in entitlement design faster than traditional applications do. The practical test is no longer whether the account can log in, but whether the system can safely decide what to read, combine, and return on behalf of the user.


For practitioners

  • Define assistant input boundaries Publish explicit rules for what data employees may place into prompts, including what is prohibited because it is not intended for public consumption.
  • Map assistant entitlements to data sources Inventory every repository, mailbox, workspace, and application the assistant can query, then confirm which datasets it should never reach.
  • Include AI assistants in access certifications Add assistant accounts, connector permissions, and retrieval scopes to regular access reviews so reviewers assess the full disclosure path.
  • Constrain outbound response scope Set response controls so the assistant can only return information that matches the user’s entitlement and the organisation’s data-silo rules.
  • Verify data retention and reuse terms Ask the vendor how prompts, data, and responses are stored, retained, and reused, and align that with your privacy and governance requirements.

Key takeaways

  • LLMs and generative AI create governance risk when prompts, entitlements, and outbound channels can move sensitive information beyond intended boundaries.
  • The article’s central concern is control drift, because access reviews and certifications were built for more predictable access patterns than assistant-driven behaviour.
  • Practitioners need to govern what assistants can query, what they can return, and how those permissions are reviewed over time.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10ASI03 — Identity & Privilege AbuseAssistant access and response rights are the core governance concern in this article.
Recommendation — Apply ASI03 to bound assistant privileges to the minimum data and actions needed.
OWASP Non-Human Identity Top 10NHI-04 — Insecure AuthenticationThe article focuses on controlling who and what can authenticate into data sources through AI tools.
Recommendation — Review assistant authentication paths and restrict connected credentials to approved scopes.
NIST AI RMFGOVERN — AI Governance and AccountabilityThe article is about governance decisions for generative AI use and accountability for access scope.
Recommendation — Establish governance ownership for AI data access, disclosure, and retention decisions.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsAccess reviews and entitlement control are central to the article’s IGA message.
Recommendation — Map assistant and connector permissions to PR.AA-05 and certify them alongside user access.
NIST SP 800-53 Rev 5AC-6 — Least PrivilegeThe article warns that assistants may have broader access than users intend or need.
Recommendation — Enforce least privilege on assistant connectors, retrieval scopes, and data-return permissions.

Key terms

  • Assistant Governance Drift: The gap that opens when AI assistant permissions, retrieval paths, and response behaviour move faster than the organisation’s governance model. In practice, the assistant becomes harder to certify than the user because its effective access depends on configuration, connectors, and output channels as much as account identity.
  • Data Scope: Data scope is the set of systems, identities, and workflows that must be included when protecting a defined data type. In CMMC programmes, scope is determined by where CUI is stored, processed, transmitted, or supported, not by what the organisation stores in general.
  • Entitlement Drift: Entitlement drift is the slow accumulation of permissions that no longer match the original purpose, role, or workload. In cloud-native and NHI-heavy environments, it usually happens because access changes faster than review cycles, leaving organizations with more privilege than they intended.
  • Response Scope: The boundary that determines what information a system is allowed to disclose back to a user or downstream system. For generative AI, response scope is as important as query scope because the main risk often lies in what the assistant reveals, not only what it reads.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org