Tag: RAG

MCP: Connecting AI to Your World

The Missing Link: How Model Context Protocol (MCP) is Connecting AI to Your World

Imagine hiring a brilliant expert who has read every book in the library but isn’t allowed to use the internet, check live data, or even open a spreadsheet on their computer. Their knowledge is vast but static, frozen in time. This is the reality for most Large Language Models (LLMs) today. They are incredibly capable but fundamentally disconnected from the real-time, dynamic world of enterprise data and tools.

Enter the Model Context Protocol (MCP). This open standard is rapidly emerging as the critical bridge that connects isolated AI models to the information and capabilities they need to become truly useful agents. In this article, we’ll explore what MCP is, how it solves major headaches for AI developers, and where it fits into your enterprise AI strategy.

What is the Model Context Protocol (MCP)?

At its core, the Model Context Protocol is an open-source standard designed to normalise how AI models interact with external systems. Think of it as a universal language that allows an LLM to say, “I need to look up the latest sales figures,” or “Please update this customer record,” and have a standardised way to communicate that request to a database, an API, or a software tool.

Before MCP, connecting an LLM to a new data source required building a custom integration—a brittle, time-consuming process that had to be repeated for every new tool. MCP replaces this fragmented approach with a single, unified protocol, enabling AI agents to connect to a vast ecosystem of data and tools in a plug-and-play manner.

Under the Hood: How MCP Functions

MCP operates on a client-server architecture, establishing a standardised two-way communication channel between the AI application and external resources.

  • MCP Host: The AI application itself (e.g., a chatbot or an AI-powered IDE) where the LLM resides and interacts with the user.
  • MCP Client: A component within the host that acts as the translator. It takes the LLM’s natural language intent and converts it into a structured MCP request.
  • MCP Server: A lightweight service that sits in front of your data sources or tools. It understands MCP requests and can execute them against the backend system (e.g., running a SQL query or calling a REST API).
  • Transport Layer: The communication channel (typically using JSON-RPC messages) over which the client and server exchange information.

The diagram below illustrates this elegant and modular flow.

Solving the “Smart but Disconnected” Problem

MCP directly addresses several critical challenges that have held back the deployment of truly useful enterprise AI:

  1. Fragmented Integration Workflows: Instead of building and maintaining dozens of custom connectors for your CRM, ERP, databases, and internal tools, you build a single MCP server for each. Any MCP-compliant AI client can then instantly interact with them.
  2. Reduced Hallucinations: By giving the LLM direct access to ground-truth data in your systems, you significantly reduce the chance of it making up information. The model can cite its sources, increasing trust.
  3. Increased AI Utility & Automation: MCP transforms an LLM from a passive knowledge retrieval system into an active agent. It can’t just tell you about a problem; it can be granted the tools to fix it, from resetting a password to reordering inventory.
  4. Standardised Context Handling: MCP provides a structured approach for defining and passing context. This ensures that different teams and systems are “speaking the same language” when providing information to the model, reducing errors and inconsistencies.

Navigate with Care: New Challenges Introduced by MCP

While powerful, opening up your internal systems to an AI model introduces new risks that must be managed carefully:

  • Security Risks: Giving an LLM the ability to execute code or query databases is a high-stakes game. Malicious actors could try “prompt injection” attacks to trick the model into performing unauthorised actions. Robust permissions, sandboxing, and human-in-the-loop verification are essential.
  • Identity and Access Management: It can be unclear whose identity the AI assumes when it takes an action. Is it acting as the user, or as a system agent? Clear identity propagation and auditing are crucial for compliance and security.
  • Token Consumption & Cost: Every piece of context sent back and forth between the client and server consumes tokens. For complex workflows with large datasets, this can quickly drive up costs and increase latency.

MCP vs. The World: Alternatives Compared

MCP is not the only way to give an LLM access to external information. It’s important to understand how it compares with other popular techniques, such as Retrieval-Augmented Generation (RAG).

RAG is primarily designed to retrieve static, unstructured data from knowledge bases (e.g., PDFs or wikis) via semantic similarity. It’s great for answering the question “What does our policy say about X?”

MCP is designed for dynamic, structured data and active tool use. It’s the right choice for tasks like “find the live status of order #12345 from the SQL database and email the customer.”

While they can be used together, they solve fundamentally different problems. The image below provides a clear comparison.

The Enterprise Verdict: When to Use MCP

MCP is a game-changer, but it’s not a one-size-fits-all solution.

It’s a great fit when:

  • You need to connect AI to diverse, siloed internal systems.
  • Your use case requires real-time data access and the ability to take action, not just retrieve information.
  • You want to build “agentic” workflows where the AI can reason and execute multi-step tasks.

It might not be the best fit when:

  • You have a very simple, stateless integration where a full protocol is overkill.
  • Extreme low latency is paramount, and the protocol’s overhead could be an issue.
  • Your team is not ready to manage the security risks of giving an AI agent access to internal tools.

As the ecosystem matures, MCP is poised to become the standard for building truly connected and capable AI agents. By understanding its power and its pitfalls, enterprises can unlock a new level of automation and intelligence.

[1]: What is Model Context Protocol (MCP)? A guide – Google Cloud

[2]: Specification – Model Context Protocol

[3]: What problems does Model Context Protocol (MCP) solve for AI developers? – Milvus

Implementing Granular Access Control in RAG Applications

A Guide to Implementing Granular Access Control in RAG Applications

Audience: Security Architects, AI/ML Engineers, Application Developers

Version: 1.0

Date: 11 September 2025

1. Overview

This document outlines the technical implementation for enforcing granular, “need-to-know” access controls within a Retrieval-Augmented Generation (RAG) application. The primary mechanism for achieving this is through metadata filtering at the vector database level, which allows for robust Attribute-Based Access Control (ABAC) or Role-Based Access Control (RBAC). This ensures that a user can only retrieve information they are explicitly authorised to access, even after the source documents have been chunked and embedded.

2. Core Architecture: Metadata-Driven Access Control

The solution architecture is based on attaching security attributes as metadata to every data chunk stored in the vector database. At query time, the system authenticates the user, retrieves their permissions, and constructs a filter to ensure that the vector search is performed only on the subset of data to which the user is permitted access.

3. Step-by-Step Implementation

3.1. Data Ingestion & Metadata Propagation

The integrity of the access control system is established during the data ingestion phase.

  1. Define a Metadata Schema: Standardise the security tags. This schema should be expressive enough to capture all required access controls.
  • Example Schema:
  • doc_id: (String) Unique identifier for the source document.
  • classification: (String) e.g., ‘SECRET’.
  • access_groups: (Array of Strings) e.g., [‘NTK_PROJECT_X’, ‘EYES_ONLY_LEADERSHIP’].
  • authorized_users: (Array of Strings) e.g., [‘user_id_1’, ‘user_id_2’].
  1. Ensure Metadata Inheritance: During the document chunking process, it is critical that every resulting chunk inherits the complete metadata object of its parent document. This ensures consistent policy enforcement across all fragments of a sensitive document.
    Conceptual Code:
    Python
    def process_document(doc_path, doc_metadata):
        chunks = chunker.split(doc_path)
        processed_chunks = []
        for i, chunk_text in enumerate(chunks):
            # Each chunk gets a copy of the parent metadata
            chunk_metadata = doc_metadata.copy()
            chunk_metadata[‘chunk_id’] = f”{doc_metadata[‘doc_id’]}-{i}”
            processed_chunks.append({
                “text”: chunk_text,
                “metadata”: chunk_metadata
            })
        return processed_chunks

3.2. Vector Storage

Modern vector databases natively support metadata storage. This feature must be utilised to store the security context alongside the vector embedding.

  1. Generate Embeddings: Create a vector embedding for each chunk’s text.
  2. Upsert with Metadata: When writing to the vector database, store the embedding, a unique chunk ID, and the whole metadata object together.
    Conceptual Code (using Pinecone SDK v3 syntax):
    Python
    # 'vectors' is a list of embedding arrays
    # 'processed_chunks' is from the previous step

    vectors_to_upsert = []
    for i, chunk in enumerate(processed_chunks):
        vectors_to_upsert.append({
            "id": chunk['metadata']['chunk_id'],
            "values": vectors[i],
            "metadata": chunk['metadata']
        })

    # Batch upsert for efficiency
    index.upsert(vectors=vectors_to_upsert)

3.3. Query-Time Enforcement

Access control is enforced dynamically with every user query.

  1. User Authentication & Authorisation: The RAG application backend must integrate with an identity provider (e.g., Active Directory, LDAP, or OAuth provider) to securely authenticate the user and retrieve their group memberships or security attributes.
  2. Dynamic Filter Construction: Based on the user’s attributes, the application constructs a metadata filter that reflects their access rights.
  3. Filtered Vector Search: Execute the similarity search query against the vector database, applying the constructed filter. This fundamentally restricts the search space to only authorised data before the similarity comparison occurs.
    Conceptual Code:
    Python
    def execute_secure_query(user_id, query_text):
        # Authenticate user and get their permissions
        user_permissions = identity_provider.get_user_groups(user_id)
        # Example: returns ['NTK_PROJECT_X', 'GENERAL_USER']

        query_embedding = embedding_model.embed(query_text)

        # Construct the filter
        # This query will only match chunks where 'access_groups' contains AT LEAST ONE of the user's permissions
        metadata_filter = {
            "access_groups": {"$in": user_permissions}
        }

        # Execute the filtered search
        search_results = index.query(
            vector=query_embedding,
            top_k=5,
            filter=metadata_filter
        )

        # Context is now securely retrieved for the LLM
        return build_context_for_llm(search_results)

4. Secondary Defence: LLM Guardrails

While metadata filtering is the primary control, output-level guardrails should be implemented as a defence-in-depth measure. These can be configured to:

  • Block Metaprompting: Detect and block queries attempting to discover the security structure (e.g., “List all access groups”).
  • Prevent Information Leakage: Scan the final LLM-generated response for sensitive keywords or patterns that may indicate a failure in the upstream filtering.

Generative AI RAG Applications: Protecting Sensitive Data Safely

The Challenge: Lost in Translation

Retrieval-Augmented Generation (RAG) is revolutionising how we access information. By connecting powerful Large Language Models (LLMs) to our private data, we can create incredibly smart assistants. But there’s a hidden security challenge: RAG applications work by shredding documents into hundreds of small chunks. What happens to the “Top Secret” stamp or the “Eyes-Only for the Finance Team” note on the original document?

Without a proper security design, these critical access controls can be lost. A user asking a general question could receive an answer synthesised from a highly sensitive chunk they were never meant to see. In secure environments, this is a non-starter.

So, how do you ensure your RAG system respects your organisation’s “need-to-know” policies?

The answer lies in making your data’s security permissions a first-class citizen throughout the entire AI pipeline.

The Solution: Smart Data with Metadata Filtering

The most robust solution is to embed your access rules directly into your data using metadata. Think of it like a digital security tag attached to every single chunk of information. When a user asks a question, the system first checks their ID card against the security tag on every chunk before even beginning its search. This is metadata filtering, and it’s the gold standard for a secure RAG.

Here are the most common approaches to implementing it.

Option 1: Attribute-Based Access Control (ABAC)

This is the most flexible and powerful approach. Each data chunk is tagged with specific attributes (e.g., caveat: ‘PROJECT_X’, department: ‘LEGAL’), and each user is assigned a set of attributes. The system grants access if the user’s attributes match the data’s attributes.

  • Pros:
    • Extremely Granular: Control access down to a single document for a single user.
    • Highly Scalable: Policies are dynamic and don’t require changing roles for every new project.
  • Cons:
    • Complex Setup: Requires a mature identity management system and careful planning to define all the attributes.

Option 2: Role-Based Access Control (RBAC)

RBAC is a more traditional and often simpler approach. Instead of fine-grained attributes, users are assigned roles (e.g., ‘Project_X_Analyst’, ‘Compliance_Officer’). Each document chunk is then tagged with the roles that are allowed to see it.

  • Pros:
    • Easier Management: Simpler to manage permissions for large groups of users.
    • Intuitive: Often aligns with existing organisational structures and roles.
  • Cons:
    • Less Flexible: Can lead to “role explosion” where you need to create dozens of roles to cover all permissions. Not great for handling one-off “eyes-only” exceptions.

Option 3: Access Control Lists (ACLs)

This is the simplest method, where each document chunk’s metadata contains a literal list of the user IDs or group IDs allowed to view it.

  • Pros:
    • Simple to Implement: Very straightforward logic for small-scale projects.
  • Cons:
    • Doesn’t Scale: Managing lists of thousands of users across thousands of documents is unmanageable and prone to errors. Best avoided for enterprise systems.

How It Works in Practice

Regardless of the model you choose (ABAC is typically best), the implementation follows four key steps:

  1. Tag at the Source: During ingestion, extract the security classifications from each document and attach them as metadata.
  2. Chunk with Inheritance: When you split the document into pieces, ensure every single chunk inherits the parent’s security metadata. This is the most critical step.
  3. Store Together: In your vector database, store the vector embedding and its rich metadata object side by side.
  4. Filter Before Searching: When a user makes a query, the system first verifies their identity and permissions. It then builds a security filter and tells the database, “Only search for answers within the chunks that match this user’s permissions.”

This ensures the LLM only ever sees data the user is already cleared to see, effectively eliminating the risk of accidental data leakage.

Final Summary

Building a RAG application for a secure environment requires treating access control as a core design pillar, not an afterthought. By embedding permissions as metadata and enforcing filtering at the database level, you can build a powerful AI tool that is not only intelligent but also trustworthy and secure. This approach transforms security from a simple gatekeeper into an integral part of the data itself, ensuring your sensitive information stays that way.