They should govern access at request time, not just at login or deployment time. The right control is to bind the human requester, the retrieved data, and the tool action together so the chatbot only receives the minimum access needed for that specific interaction.
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.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Request-time chatbot governance depends on strong auth context for each interaction. |
| NHI-05 — Overprivileged NHI | RAG and MCP both fail when the chatbot retains more access than the current task needs. | |
| NHI-06 — Insecure Cloud Deployment Configurations | Misconfigured RAG stores and MCP endpoints can expose data or tools beyond policy. | |
| Recommendation — Bind each request to a verified requester and short-lived authority before allowing retrieval or tool use. Reduce chatbot permissions to the minimum authority needed for the current request. Harden deployment boundaries so retrieval stores and MCP servers cannot bypass access policy. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The question centers on preventing a chatbot from acting beyond delegated authority. |
| ASI02 — Tool Misuse | MCP specifically introduces tool access that must be governed per request. | |
| ASI09 — Human-Agent Trust Exploitation | Users may overtrust chatbot outputs or actions when retrieval and tool use are fused. | |
| Recommendation — Enforce per-action authorization so agents cannot exceed the requester’s delegated scope. Authorize each tool invocation against the current intent, context, and policy. Require visible approval points for high-impact actions and sensitive retrievals. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Request-time control requires enforcing access decisions on each data read and tool action. |
| AC-6 — Least Privilege | The model must grant only the minimum data and tool authority needed for the interaction. | |
| Recommendation — Enforce access decisions at the moment of retrieval or execution. Scope chatbot permissions to the smallest set of resources and actions required. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The subject is about governing who can access data and perform actions through the chatbot. |
| Recommendation — Centralize and review chatbot access rules for data retrieval and tool execution. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The question is about binding identity and access to the actual request across chatbot capabilities. |
| Recommendation — Tie user identity and access decisions to each retrieval and tool invocation. | ||
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.