How should security teams govern chatbot access when RAG and MCP are both in use?

How to govern chatbot access when RAG and MCP both exist

When a chatbot can both retrieve private material through RAG and invoke tools through MCP, governance has to move from static access at login to contextual access at request time. The security question is not simply who may use the chatbot, but what that specific request may see, what it may call, and whether the requester is entitled to both. The control boundary should follow the interaction.

Why request-time binding matters more than a login-only model

RAG and MCP create two different paths for overreach. RAG can surface data the user should not see, while MCP can let the chatbot act beyond the user’s intended authority. If those paths are governed separately, the chatbot becomes a bridge between permission gaps. Binding the human requester, retrieved data, and tool action into one authorization decision keeps the access decision aligned with the actual task, not the session that happened to start it.

That means the system should not treat chatbot authentication as proof of entitlement to all embedded capabilities. A valid session only proves entry. The real decision is whether the current prompt, the current user, the current data scope, and the current tool call together satisfy policy. In practice, this is the difference between “allowed to use the assistant” and “allowed to read this document and execute this action for this reason.”

What the governance model should cover across RAG, MCP, and data use

The strongest model is request-scoped authorization with three linked checks. First, the retrieval layer should enforce user permissions so the model only sees content already available to that requester. Second, the tool layer should authorize each action separately, because MCP access can be safe for one tool and unsafe for another. Third, the policy decision should reflect the intent of the request, so the same user can be allowed to summarise a record but not to modify it, export it, or trigger a downstream workflow.

This is also where teams need clean ownership. Retrieval permissions, tool permissions, and application policy should not be managed as three unrelated controls. If the RAG store, the MCP server, and the chatbot runtime each make independent decisions, drift and bypasses become likely. A coherent governance model defines which system is authoritative for identity, which is authoritative for data entitlement, and which is authoritative for tool execution.

For deeper practitioner guidance on the RAG side, see Permission-Aware RAG Guide, which focuses on enforcing user permissions at retrieval. For the MCP side, MCP Security Guide covers the authorization model, token handling, and the confused deputy problem in more detail.

How to make the control operational without breaking usability

The practical goal is not to slow every chatbot interaction, but to make privilege precise. Use short-lived, task-scoped access where possible, and require per-action policy checks when the chatbot crosses from answering to acting. Keep the authorization context rich enough to include user identity, retrieved sources, tool target, and the proposed action, otherwise the policy engine will only approximate the real risk.

Teams should also monitor for mismatches between retrieved content and tool authority. If a chatbot can cite information it could not have legitimately retrieved, or invoke tools unrelated to the request, that is a sign the governance model is too coarse. A good operating rule is simple: if the system cannot explain why this user needed this data and this tool at this moment, the access model is too broad.

For implementation patterns that align with per-request authority and delegated action, the broader agent controls in AI Agent Authorisation Guide are useful, even when the interface looks like a chatbot rather than a full agent.

Risk and Threat Considerations

RAG and MCP expand the blast radius of a chatbot because one path can expose data and the other can execute action. If access is granted only at login, an attacker, a careless user, or an overbroad connector can combine a legitimate session with an illegitimate retrieval or tool call. The most common failure is a confused-deputy condition, where the chatbot is trusted to mediate authority but ends up laundering access across systems.

Failure mechanism: Permissions are checked too early or too generically, so the chatbot inherits standing access that is broader than the current request, enabling over-retrieval, over-action, or both.

Impact: Sensitive data exposure, unauthorized tool execution, and policy bypass can occur even when the user’s original login was legitimate.

Practitioner Guidance

What to verify: Confirm that authorization is evaluated at the request layer, not just at authentication, and that the policy decision includes the requester, the retrieved context, and the target tool or action.

Decision rule: If the chatbot can either read protected content or perform a side-effecting action, require separate entitlement checks for each, with the tighter rule winning whenever the two disagree.

What good looks like: A request can only retrieve sources the user already has rights to see, and every MCP action is bounded to the minimum authority needed for that exact interaction.

Practitioner takeaway: Treat the chatbot as a policy enforcement point, not a trusted shortcut, because the security boundary is the individual request, not the chat session.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern access when LLMs use MCP servers?
• How should security teams govern non-human identities at scale?