AI chatbot identity crisis: why RAG and MCP need tighter controls

At a glance

What this is: This is an analysis of how AI chatbots that use LLMs, RAG, and MCP reshape identity and access control by turning assistants into systems with execution authority.

Why it matters: It matters because IAM and NHI teams now have to govern both the human requester and the AI path through data, tools, and downstream actions.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read SGNL's analysis of chatbot identity risk, RAG, and MCP access

Context

AI chatbots are no longer just text interfaces. Once they can retrieve internal data and trigger actions through MCP, they behave more like non-human identities than simple software features. That changes the governance question from what the user may see to what the AI system itself may access, infer, and execute. For practitioners, the primary issue is not model quality alone. It is whether identity controls can still contain the blast radius when an autonomous system is allowed to move across data sources and operational tools.

The article argues that static permissions are too coarse for AI-driven workflows because access decisions have to reflect the human requester, the requested task, and the data path in real time. That is a familiar IAM principle, but the scale and speed are new. For readers looking for a broader framing of NHI governance, the Ultimate Guide to NHIs remains a useful reference point for lifecycle, visibility, and access control patterns.

Key questions

Q: How should security teams govern AI chatbots that can access internal systems?

A: Security teams should govern AI chatbots as non-human identities with explicit ownership, scoped entitlements, and continuous authorization. The chatbot should only reach the data and tools required for the task, and every prompt should be evaluated against the human request, context, and downstream action before access is granted.

Q: What is the difference between RAG access and MCP tool access?

A: RAG access controls what information the model can retrieve and place into context, while MCP tool access controls what the system can do with that context. Retrieval risk is mainly exposure, but tool risk includes execution. Both need separate policy boundaries because a safe read path can still feed an unsafe action path.

Q: When does an AI assistant create more identity risk than a normal application?

A: An AI assistant creates more identity risk when it can combine retrieval, reasoning, and action inside one workflow. That increases the blast radius because a single prompt can lead to sensitive data exposure or an unauthorized operational change. Risk rises sharply when permissions are broad, inherited, or not reevaluated per request.

Q: Why do AI assistants complicate zero trust architecture?

A: AI assistants complicate Zero Trust Architecture because they can change context after initial authentication. A login event is not enough when the system can retrieve new data, invoke tools, or take actions mid-session. Zero Trust needs continuous verification, fine-grained scope, and revocation that follows the request lifecycle.

Technical breakdown

Why LLM, RAG, and MCP chains change the trust model

An LLM generates responses, RAG supplies external context, and MCP standardizes access to tools and data sources. Together they create a chain where the model can move from retrieval to action, which means identity is no longer limited to human login events. The trust boundary shifts to the full request path, including what data is retrieved, what context is passed to the model, and what downstream system actions are permitted. If any link in that chain is overbroad, the AI system can expose or act on information the user should not reach. That makes the AI workflow a governance object, not just an application feature.

Practical implication: Map each AI request to the data sources and tools it can touch, then constrain each hop with explicit policy.

How MCP expands NHI exposure through tool permissions

MCP gives models a common way to discover and use tools, but discovery is not the same as authorisation. If a chatbot can enumerate tools broadly or inherit excessive permissions, it can become a path to secrets, internal records, or operational commands. In NHI terms, the AI system is using non-human credentials and permissions that need the same scrutiny as service accounts or workloads. The risk is not only exfiltration. It is also unauthorized action, because tool access can become an execution channel rather than a read-only integration.

Practical implication: Treat MCP tool access as privileged NHI access and scope permissions to the smallest viable task set.

Continuous authorisation is the control layer static IAM cannot provide

Traditional IAM is built around relatively stable identities and policy decisions at login or session creation. AI workflows are more dynamic because the requested action, retrieved context, and downstream tool use can change from one prompt to the next. Continuous authorisation closes that gap by re-evaluating access in real time as the workflow unfolds. That matters when an assistant can pull sensitive data and then trigger a business action in the same flow. Without that recheck, the system can remain trusted long after the context that justified access has changed.

Practical implication: Require real-time policy evaluation for retrieval, tool invocation, and action approval in the same workflow.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI chatbots have become NHI governance problems, not just application design problems. Once a chatbot can retrieve data and invoke tools, it behaves like an identity with delegated authority. That delegation needs lifecycle management, access review, and scope control just like any other non-human identity. The discipline shifts from model supervision to governing what the system can do on behalf of a human. Practitioners should classify AI assistants as governed identities, not passive interfaces.

Ephemeral access reduces exposure, but it does not remove trust debt. A short-lived token or prompt-scoped permission window is better than a standing entitlement, yet the underlying trust decision still has to be correct. If retrieval scope, tool permissions, or action rights are misaligned, the same mistake repeats at speed. The practical lesson is that JIT-style patterns help only when they are paired with task-level authorisation and revocation logic. Otherwise, the organisation is simply issuing smaller bad decisions.

Identity blast radius is the right concept for AI assistants. The important question is no longer only who authenticated, but how far the assistant can move once authenticated. That blast radius spans retrieval stores, APIs, workflows, and downstream systems, which means every extra permission expands the cost of a prompt compromise or misuse event. Security teams should measure AI access in terms of reachable systems and reachable data, then reduce both.

Continuous verification is now the default expectation for AI-mediated access. Zero Trust Architecture assumes breach and requires repeated proof of legitimacy, which aligns with AI workflows far better than static role assignment. AI systems can change context mid-session, so authorization has to follow the request rather than the login. The governance answer is to keep the model narrow, the permissions specific, and the execution path observable.

RAG governance and MCP governance should be reviewed together. Retrieval scope controls what information enters the model, while MCP controls what actions leave the model. Separating those controls creates blind spots because a safe retrieval path can still feed an unsafe execution path, and vice versa. Practitioners should design both layers as one policy domain. That is the only way to keep AI assistants inside their intended authority.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, which helps explain why tool sprawl quickly becomes a governance problem.
• To go further, the Ultimate Guide to NHIs connects lifecycle controls, rotation, and access review to the broader identity governance model.

What this signals

AI assistant adoption is forcing identity teams to treat retrieval and execution as one governed path. The programme implication is straightforward: if the organisation cannot explain what an assistant may see and do at each step, it does not yet have control of the system. With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, per The State of MCP Server Security 2025, the risk is already operational rather than theoretical.

Identity blast radius: this is the more useful design metric for AI-mediated access. Teams should track how far a compromised prompt, token, or tool connection could move across data sources and production systems, then reduce that reach before scaling agent use. The best next step is to align AI governance with the Ultimate Guide to NHIs and Zero Trust principles.

Programmes that already separate retrieval from execution will adapt faster than those relying on broad application roles. The practical signal is to tighten approval flows, expand audit logging, and make revocation fast enough to interrupt an active misuse path. That work fits naturally with OWASP Non-Human Identity Top 10 guidance on overprivilege and secret handling.

For practitioners

• Classify AI assistants as governed identities Assign each chatbot or agent an owner, a scope, and a review cycle. Treat its retrieval paths, tool permissions, and downstream actions as entitlements that require periodic access review, not one-time configuration.
• Enforce task-scoped authorization for every prompt Require policy evaluation at retrieval time and again before any tool invocation or workflow action. The control should verify the human requester, the task context, and the minimum data required for the response.
• Separate read access from execution access Do not give the same AI workflow permission to both collect information and trigger business actions unless the use case truly requires it. Split those rights so a prompt compromise cannot automatically become an operational change.
• Reduce MCP permission scope before scaling usage Inventory each tool exposed through MCP, then remove broad access, unused capabilities, and inherited privileges. Start with the smallest viable tool set and expand only when the business case and audit trail justify it.
• Instrument AI sessions for audit and revocation Log which prompts led to which data sources and tool calls, then make revocation fast enough to matter during an active incident. The goal is to shorten the time between misuse detection and access removal.

Key takeaways

• AI chatbots become NHI governance issues once they can retrieve data and trigger actions, because the identity question shifts from login to delegated authority.
• The real risk is not just exposure of information but expansion of blast radius when retrieval, tool use, and execution sit in one workflow.
• Security teams should scope AI permissions per task, separate read from execute rights, and enforce continuous authorization across the full request path.

Key terms

• Model Context Protocol: Model Context Protocol is an open way for AI applications to connect models to tools and data sources. In security terms, it turns a model from a text generator into an entity that can discover resources, retrieve context, and potentially trigger actions, which makes access scope and authorization central controls.
• Non-Human Identity: A non-human identity is any machine, service, token, certificate, workload, bot, or AI agent that authenticates and accesses systems. It needs governance because it can carry privileges, persist beyond a user session, and expand its reach silently if ownership, rotation, and access scope are weak.
• Continuous authorization: Continuous authorization is the practice of rechecking access as a session unfolds instead of trusting a single login decision. It matters for AI workflows because the request, context, retrieved data, and downstream action can all change between prompt and execution, making static approval too blunt.

Deepen your knowledge

AI chatbot governance, RAG scope control, and MCP access design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are turning assistants into governed identities, this is the right baseline to build from.

This post draws on content published by SGNL: Chatbots, AI, and the identity crisis we didn't see coming. Read the original.