Identity, Authorization, and Tenant Isolation

In a traditional application, the system checks whether the user is allowed to access a record or perform an action. In an AI-enabled application, the assistant often sits between the user and those backend systems. That introduces a dangerous temptation: to let the assistant fetch or do things because the workflow feels helpful, even if the user would not normally have direct access.

Blue teams need to prevent that drift. The assistant should operate within the same real authorization boundaries as the user and the business workflow. It should not become a side door into data or actions the user could not reach otherwise.

The model may sound confident, but it is not the authority. The underlying access policy still is.

Retrieval systems can fail authorization when they search across too much data, ignore tenant labels, or surface documents outside the user's legitimate scope. That can happen because metadata is missing, filters are weak, or the system is built around one large shared corpus without strong separation.

A cross-tenant leak does not require an explicit tool action. It can happen if the assistant simply retrieves or summarizes another customer's material and presents it to the wrong user. That is why tenant-aware filtering and document-level access controls matter so much in RAG systems.

If the assistant can retrieve it, the assistant can potentially expose it.

Tool-enabled assistants must also preserve identity when they call backend services. A dangerous design is one where the assistant uses a broad service credential and bypasses the user's real permissions. That may feel convenient to developers, but it can turn the model into an over-privileged intermediary.

Better designs propagate user identity, role, tenant, and purpose into the tool call so the backend can make the correct authorization decision. If that is not possible, defenders should narrow the service account sharply and add stronger approval, logging, and review controls.

The goal is not only to know who asked the question. It is to ensure the entire chain of retrieval and action respects that identity.

A blue-team review for identity and tenant isolation usually asks: what identity reaches the retriever, what filters are mandatory, what identity reaches the tool, who approves sensitive actions, and how the system proves that one user's content cannot appear in another user's answer.

Reviewers also look for service accounts with too much privilege, missing tenant tags, weak access propagation, and workflows that assume the model can safely decide what the user should be allowed to do.

Strong authorization design keeps the assistant useful without letting convenience become silent privilege escalation.

Name one way an assistant can accidentally exceed the user's real permissions.

Name two pieces of context that should usually survive into retrieval or tool authorization.

Name one control that helps prevent cross-tenant retrieval or action leakage.