The governing principle is one sentence, and almost every failure in this area is a departure from it. An AI system must not become a way around the authorization model an organization already has.
That sounds obvious. It is violated routinely, and usually not by anyone deciding to violate it. It is violated because the straightforward way to build an assistant that can answer questions about company material is to give the assistant broad access to company material.
Two questions that get conflated
Who may use the system. Ordinary authentication: your identity provider, single sign on, multi factor authentication, and the same joiner and leaver process as every other application. This part is well understood, and where it goes wrong it goes wrong for ordinary reasons, such as a departmental subscription bought outside the identity estate.
What the system may reach on that person's behalf. This is the part specific to AI, and it is where the design decision hides. Authenticating a user tells you who is asking. It says nothing about what should come back.
A system that authenticates carefully and then queries every source with one service account has an identity model in name only. It will answer correctly, helpfully, and sometimes with content the asker could not open in the source system. Nothing about the response indicates that this has happened.
Why the shortcut is so attractive
Worth stating plainly, because teams that take it are not being careless.
Propagating a user's identity across an application, a retrieval service and several source systems is real work. Each source has its own permission model. Some expose it through an API and some do not. Group membership resolves differently in different systems. Meanwhile a single service account with broad read access works immediately and demonstrates well.
The cost arrives later, and it arrives as a disclosure that is difficult to detect, because the system behaved exactly as built. NIST's SP 800-207 states the general principle: there is no implicit trust granted to assets or user accounts based solely on their physical or network location. A retrieval service inside your network has earned nothing by being there.
Identities an AI environment contains
More than most systems, which is part of why access review is harder here.
- People. Staff, contractors, and sometimes customers, each with an existing entitlement set that should govern what they see.
- The application. The assistant itself, which needs to reach the model and the index.
- Retrieval and connector identities. Whatever reads the source systems, and the point at which the shortcut is usually taken.
- The model endpoint. Credentials for a provider API or an internal serving layer, covered in enterprise AI API security.
- Tool and action identities. Where the system can do rather than only answer, whatever performs the action, which may be a distinct identity with distinct rights.
- Administrative identities. Whoever can change prompts, sources, connectors or permissions, which is the most privileged category and the least often reviewed.
Each needs an owner, a scope and a review. An environment where the connector's rights are unknown is an environment whose effective permissions nobody can state.
What good looks like
Identity travels the whole way
The retrieval query executes with the asker's effective permissions, evaluated at query time rather than at ingestion time only. A user whose access was removed this morning stops seeing that content this morning. The mechanics inside the retrieval pipeline, including caching and conversation history, are covered in secure RAG architecture.
Least privilege applied to services, not only people
Service identities accumulate scope, because each new source is easier to add to an existing credential than to justify separately. Scoping each connector to the repositories it actually needs, and reviewing that on a schedule, is the control. A connector with organization wide read access is a standing decision that everything is in scope.
Attribute based decisions where roles are too coarse
Role based access assigns permissions to job functions and is sufficient for most systems. Where content sensitivity varies within a role, attributes on the content, classification, owning department, matter or client, give a finer basis for a decision. Most organizations need both: roles for the application, attributes for the content.
No standing privilege for administration
Changing which sources are indexed, or what the system may do, are consequential actions. They deserve the treatment other privileged operations get: elevation when needed rather than permanently, and a record of who changed what.
Deprovisioning that actually reaches the AI estate
Removing an account should remove access to the assistant, its history, and anything it created on that person's behalf. Where AI tools sit outside the identity estate this fails silently, and nobody notices because a departed employee's continued access produces no visible event.
Authentication strength, and where the guidance comes from
NIST publishes Digital Identity Guidelines, SP 800-63-4, in July 2025, superseding SP 800-63-3. It covers identity proofing, authentication and federation, and is a useful reference for the concepts and for the vocabulary of assurance levels.
Its scope is worth stating accurately: it addresses users who interact with government information systems. A private organization is not bound by it and can still take the concepts, which is how most of the industry uses it. Treating it as an obligation on a commercial deployment is a claim it does not make.
Practically, an AI assistant with access to organizational knowledge deserves the authentication strength given to the most sensitive system it can reach through, which is frequently stronger than the assistant was originally set up with.
Agents raise the stakes on decisions already made
Where a system can act rather than only answer, everything above becomes load bearing. The action runs under some identity, and if that identity is broad then a compromised or misdirected instruction has broad reach. OWASP tracks this as LLM06:2025 Excessive Agency in its Top 10 for LLM Applications.
The controls are the ones above applied more strictly: a distinct identity per capability, scoped narrowly, with an approval step where the action is consequential and a record of what ran. An agent operating with a human's full entitlements is not an assistant; it is that human's access, exercised by software.
Two complications that arrive with real estates
Permissions resolve differently in different systems. A group in your directory is not necessarily the group a document library uses, sharing links can grant access outside any group, and inherited folder permissions may not match what an API reports. A retrieval layer that reconstructs entitlements from one source will be wrong about the others, which is the argument for asking each source system what a user may see rather than deciding centrally.
External people exist. Contractors, client users and partners are frequently in scope for an assistant and frequently outside the main identity estate. Federation handles this properly; the alternative that appears first is a set of local accounts with no leaver process attached. If external access is planned, deciding how those identities are governed belongs at design time, because retrofitting it means re-examining every entitlement the system already grants.
Questions worth asking about an existing deployment
- Under whose identity does the retrieval query actually execute?
- What can the connector read, and who last reviewed that scope?
- If a user loses access to a source, how long until the assistant reflects it?
- Who can change which sources are indexed, and is that recorded?
- Does deprovisioning reach the AI tools, and how was that verified?
- If the system can act, under which identity, and with what limit?
An environment that cannot answer the first question does not yet have an access model, whatever its documentation says.
Where to go next
The retrieval side is secure RAG architecture and the credential side is enterprise AI API security. The wider sequence is how to build a private AI environment.
LABUSA provides AI identity and access design as a scoped engagement, and it is frequently the piece that turns a promising pilot into something that can carry real material. Get in touch to discuss it.
Sources and further reading
- National Institute of Standards and Technology, Zero Trust Architecture, SP 800-207, August 2020.
- National Institute of Standards and Technology, Digital Identity Guidelines, SP 800-63-4, July 2025, superseding SP 800-63-3. Scoped to users of federal government information systems; cited here for the concepts.
- National Institute of Standards and Technology, Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Revision 5.
- OWASP GenAI Security Project, OWASP Top 10 for LLM Applications, 2025, including LLM06 Excessive Agency.
Every source above was opened and read on 20 August 2026.