Connecting Large Language Models (LLMs) with external data sources and APIs opens up powerful new capabilities, and Model Context Protocol (MCP) is all the hype now. Yes, well… that’s not enough for me, personally. So let me explain my motivations for the journey here:

Normally, I am more on the “resist the hype, keep calm and code on” page, but to be fair, AI has some interesting capabilities and won’t go away shortly, so at least with MCP there’s now an open standard for tool usage. So… consider me skeptic in general, but (always) curious.

Now, for the last months I tried adding AI to my daily workflow, on different occasions (from ChatGPT usage to API-usage, to RAG, to modernization approaches). I tried and still try to be open minded. It is really another style of programming, and you really have to get away from the “100% determinism”-paradigm, for better or worse, if you dive into it.

That said, for a while now, I wanted to use an LLM as “natural language frontend” for the area I am actually interested in - access management, especially beyond Role Based Access Control (RBAC).

The concepts laid out in the ABAC and ReBAC World are pretty alien to many, as “roles” is the status quo, and it’s hard to open up nearly-hardcoded mental models to new paradigms. So, I needed a way to “easily” share the benefits of ABAC and ReBAC with a broader, not tech-savvy audience.

This article and the accompanying GitHub repository was created with the above goal, to explore access management beyond RBAC together with MCP, the aforementioned open standard that makes it easy to plug any data source to any large language model. The MCP Server we’ll build should give us exactly the “easily usable by everyone”-Frontend.

So, what will we experience on our journey?

For now, please fasten your seatbelts and relax, here we go!

What is the Model Context Protocol?

The Model Context Protocol (MCP) is a new protocol, created to define a standardized way on how AI applications (Clients) speak with external systems, be it the file system, a database or an API, through tools living on servers.

In essence, MCP is a universal interface between LLM-based applications (Clients) and external data or functionality (servers) providing capabilities (tools). Think USB, but for AI integration.

Just as USB, MCP provides a common connector spec for all sorts of connectors. It defines a common protocol so that any MCP Client with any underlying LLM that talks MCP can communicate with any MCP server.

Instead of building custom connectors for every LLM or AI application, you can adhere to the MCP spec, build your tool or Client once, and gain compatibility to all others that “talk” MCP. As a result, MCP reduces the integration effort and makes it easier to create an extensive ecosystem.

Diagram titled 'MCP-Overview' showing communication flow between an MCP Host, MCP Server, and external services like API, Database, and Filesystem.

As you can see in the picture, an MCP Client is typically an AI application that invokes external tools. The MCP server is a typically local application, as you see in the picture. It exposes a set of tools (and more) defined through the MCP protocol. Simplified, it’s pretty well-known client-server-communication. The first remote MCP servers have also been seen in the wild, but we won’t look at those further.

Finally, a security disclaimer: MCP as a Spec is very new, and it is aiming(!) to add security-related stuff from the start, but it is simply not there yet. There are some holes and vague statements currently, as all of this is pretty new and experimental.

A concrete example: As of the latest spec just released on March 26nd under “Authorization” (sic!), the server should authenticate requests and the client should ensure only allowed tools are invoked - but just for HTTP.

For an STDIO-based server like the one we’ll implement through our journey, it gets even more vague:

Implementations using an STDIO transport SHOULD NOT follow this specification, and instead retrieve credentials from the environment.

which leaves huge room for interpretation. For example, we’d be spec-compliant if we just put a plaintext file with credentials somewhere. Would that be secure, though? No.

As said, the spec is “just released” in its second version, so I think we’ll see much progress in the future on those topics. For now, as a disclaimer: handle with care. I’ll dive deeper into the security implications at the end of this article.

Diagram of 'MCP-Overview p2', showing communication between MCP Client and MCP Server via a standardized protocol.

Let’s get started: A Local MCP Server with SpiceDB

Now that we understand MCP at a high level, let’s first look at our goal, and why we use SpiceDB, so we can build an actually useful example.

Our MCP Server will connect to a local, containerized SpiceDB instance to answer important questions in the realm of access management, especially in the context of a “before the fact audit”, as defined by NIST in this document in chapter 3.1.2.3. Let’s dive quickly into this chapter. It states:

Some enterprises may desire the ability to review the capabilities associated with subjects and their attributes and the access control entries associated with objects and their object attributes. More succinctly, there are some requirements to know what access each individual has before the requests are made. This is sometimes referred to as “before the fact audit”.

As of my experience, there are more companies than one would think, that actually want

  1. Fine-grained access control mechanisms, as their customers and internal workflows demand them.
  2. A company- and portfolio-wide overview about who has access on what, with the ability to ask not only “yes/no”-question, but also open questions, like “who can access file x?” or “what access does y have on z?”

Having a natural language frontend to understand the advantages of newer access management approaches, especially the reverse indexable nature of ReBAC systems and the resulting capabilities, is of value. It answers the question “why would I want a ReBAC-System instead of RBAC?” in a very approachable way, so ordinary people can explore ReBAC on their own - with normal language, just by asking the right questions.

SpiceDB Schema and Graph-Concepts

SpiceDB lets us define a schema describing the connection of subjects (users), resources (documents, folders, files, etc) and relationships (like “user A is a member of team T” or “team U can pull containerimage Z”).

These are internally stored in a graph, where the edges are called relations and nodes subjects or resources (“definitions”). Relationships are then abstracted away behind permissions in the schema. Those permissions allow some arithmetic operations.

The well-readable semantics of the schema language allow us to answer the usual “yes/no-questions” a Policy Decision Point (PDP) has to answer (e.g. “Can user Bob access Document doc.pdf?”), but also allow us to ask “open questions” (e.g. “What can user Bob access?”).

For our scenario, imagine you want to build a Document Management System (DMS) for a multi project environment. You need access on the document level, and you don’t want to use roles for every document or other resource that exists in your company. This would lead to role explosion.

Typically, you either decide to go with more coarse-grained access, often leading to overly permissive access rights, or you’ll have a really hard time managing all those view_doc_a,view_doc_b,view_doc_123456789, write_doc_a...-roles. In a nutshell, that’s the problem ReBAC (and ABAC) solve.

For our backend, we will run SpiceDB locally using Docker. We prepare our schema that defines some basic definitions, relations and permissions for our scenario.

In our schema, we have the following definitions that resemble nodes on the internal graph:

Our example schema looks like this:

schema: |-
  definition user {}

  definition team {
    relation member: user
  }
  definition project {
    relation administrator: user
    relation team : team
    permission contribute = team + administrator
    permission admin = administrator 
  }

  definition folder {
      relation owner : user | team#member
      relation parent_project: project
      relation reader: user | team#member
      permission read = reader + parent_project.any(admin)
      permission admin = owner + parent_project.any(admin)
  }

  definition document {
    relation owner : user
    relation parent_folder: folder
    relation reader: user | team#member
    relation writer: user | team#member

    permission view = reader + writer + parent_folder.any(read)
    permission admin = owner + parent_folder->admin
  }

You can see some permission logic defined in this schema. For example: A document’s view permission might be granted to subjects directly related to readers/writers, or given to anyone who has read permission on the parent folder. Similarly, read- and admin access to a folder is inherited by a parent projects administrator.

Now that our schema is ready, we provide some actual test data to bring our schema to life:

relationships: |
  project:smallproject#administrator@user:lead1

  team:smallprojectteam#member@user:smallprojectmember1

  folder:smallprojectroot#parent_project@project:smallproject
  folder:smallprojectroot#reader@team:smallprojectteam#member
  ...

  // big project
  project:bigproject#administrator@user:CTO

  ...
  //folders
  ...

  //search subfolder
  folder:search#parent_project@project:bigproject
  folder:search#owner@user:searchteamlead1
  ...
  //docs
  document:readme#owner@user:CTO
  document:readme#parent_folder@folder:bigprojectroot

  document:search1#owner@user:searchteamlead1
  document:search1#parent_folder@folder:search
  ...

The above relationship tuples are an excerpt from the test data used in the actual implementation over on GitHub - make sure to clone the repo to follow along further.

Anatomy of a SpiceDB relation tuple

Let’s understand the language a bit more by looking at one of our entries, called a relations tuple:

Diagram illustrating a structured relationship model with segments for resource type, resource ID, permission, subject type, and subject ID, labeled with an example: 'document:search1#owner@user:searchteamlead1'.

To read this tuple, We’ll start from the right, the “subject”. We see searchteamlead1 is of type user. Next is the permission / relation part, where owner is the used relation, meaning “User Searchteamlead1 is owner of …”, which leads us to the last part: What does our team lead own? That’s the resource, also using <type>:<id>-Syntax.

So, from right to left, you can read this relation as “User searchteamlead1 is owner of document search1”. And that’s it. After all, pretty straight-forward compared to some ABAC policy languages, I’d say.

Starting up our SpiceDB Backend

To run SpiceDB with this schema and our test data, we use a Docker Compose setup. The Compose file uses the official authzed/spicedb image and bootstraps our instance, loading our schema and relationship data on startup.

We also run SpiceDB in development mode with an insecure gRPC port (50051) exposed, and define a static pre-shared key (PSK) testkey for accessing it. All our credentials are contained in our .env-file.

Launching our backend is simple: Just run

docker compose --env-file .env up -d

and you are good to go.

Once running, you might want to use the SpiceDB CLI-Tool zed to sanity-check that everything works correctly. ZED is also useful for double-checking the results our MCP-tool provides us later on. See the readme section in the accompanying repository for a more in-depth overview of its usage.

Okay, at this point we have an idea of what SpiceDB is, and our backend is ready to be called. Great!

Overview of our MCP Server solution

Next, we implement our MCP server in C#. I used C# here because half of my professional life, I worked with C#, and also because the official MCP SDK for C# just released, and I wanted to try it out. The concepts, however, would be similar in other languages.

Our MCP server is essentially an empty .net9 console application. Using the MCP SDK, we define a set of tools that we want to expose to our local MCP Client - we use Claude Desktop here, but the beauty of MCP is that it is pluggable to any other client that supports MCP. The SDK does the heavy lifting here by abstracting away the underlying MCP spec.

Our server implements the following tools corresponding to SpiceDB’s API calls:

In the accompanying GitHub repository, the following endpoints are also implemented. They are omitted for the sake of the articles' length:

Setting up our C# project

Let’s get going with our SpiceDB MCP Server. I’ll assume .net9 is already installed on your system, and you have some familiarity with the beautiful C# language.

We’ll start by creating our project folder:

mkdir spicedb-mcp

Inside this folder, we create a new dotnet console project:

cd spicedb-mcp
dotnet new console

This creates our initial project structure with a solution and a Program.cs file.

Now we install the required NuGet Packages:

dotnet add package ModelContextProtocol --prerelease
dotnet add package Microsoft.Extensions.Hosting
dotnet add package Authzed.Net

To verify, let’s look at our spicedb-mcp.csproj file, where you should see these lines appearing:

<ItemGroup>
    <PackageReference Include="Authzed.Net" Version="1.3.0" />
    <PackageReference Include="Microsoft.Extensions.Hosting" Version="9.0.3" />
    <PackageReference Include="ModelContextProtocol" Version="0.1.0-preview.4" />
</ItemGroup>

Make sure you use --prerelease when installing the MCP SDK package, as it is not available as a stable package yet.

Preparing the backend communication

First, we’ll open our Program.cs file and remove all pre-existing content.

Then, we add our MCP environment:

var builder = Host.CreateEmptyApplicationBuilder(settings: null);

builder.Services.AddMcpServer()
    .WithStdioServerTransport()
    .WithToolsFromAssembly();

Our MCP Server uses STDIO as transport medium to its client (Claude Desktop). You can think of it as a shell the AI application uses for questions and answers. Using CreateEmptyApplicationBuilder here instead of the more usual CreateDefaultBuilder ensures, that our server won’t write unwanted additional messages on the console.

With the WithToolsFromAssembly() method, the MCP SDK automatically scans classes marked with the attribute [McpServerToolType] and their methods marked with [McpServerTool] from our assembly and exposes those as MCP tools.

Next, we add the SpiceDB SDK services as Singletons.

SpiceDB uses gRPC services per default, which in term uses HTTP/2 which requires TLS normally. We use a dev-gRPC-Setup with fake credentials here for experimental purposes, though it is very important in basically all other environments to use TLS.

The following code sets up a SchemaServiceClient from the SpiceDB SDK that allows us to get the SpiceDB schema, and a PermissionServiceClient to call the Lookup- and Check-Endpoints.

Note: Using-Statements and the helper class CompositeCredentials are omitted again, you can find the complete code inside the repository

builder.Services.AddSingleton<SchemaService.SchemaServiceClient>(_ =>
{
    var callCredentials = CallCredentials.FromInterceptor((_, metadata) =>
    {
        var testToken = Environment.GetEnvironmentVariable("SPICEDB_PSK") 
                        ?? throw new Exception("No SpiceDB token provided.");
        metadata.Add("Authorization", $"Bearer {testToken}");
        return Task.CompletedTask;
    });
    
    var grpcCredentials = new CompositeCredentials(ChannelCredentials.Insecure, callCredentials);
    var channel = GrpcChannel.ForAddress("http://localhost:50051", new GrpcChannelOptions
    {
        Credentials = grpcCredentials,
        UnsafeUseInsecureChannelCallCredentials = true
    });
    
    return new SchemaService.SchemaServiceClient(channel);
});

builder.Services.AddSingleton<PermissionsService.PermissionsServiceClient>(_ => 
{
    var callCredentials = CallCredentials.FromInterceptor((_, metadata) =>
    {
        var testtoken = "testkey";
        metadata.Add("Authorization", $"Bearer {testtoken}");
        return Task.CompletedTask;
    });
    
    var grpcCredentials = new CompositeCredentials(ChannelCredentials.Insecure, callCredentials);
    var channel = GrpcChannel.ForAddress("http://localhost:50051", new GrpcChannelOptions
    {
        Credentials = grpcCredentials,
        UnsafeUseInsecureChannelCallCredentials = true
    });
    
    return new PermissionsService.PermissionsServiceClient(channel);
});

One thing to note about the SpiceDB SDK integration is we’re using an environment variable here to set the pre-shared key that authorizes the SDK Client to communicate with SpiceDB. We’ll come back to that when we integrate our MCP server into our MCP Client.

Finally, we add

var app = builder.Build();
await app.RunAsync();

so our configuration is applied, and the app starts up correctly. For now, we’re all set, so let’s finally implement our tools.

Creating our first tool

To implement our tool, we create another class named SpiceDbTools.cs in our solution, containing the following outline:

[McpServerToolType]
public static class SpiceDbTools
{
    // TODO

}

The Attribute [McpServerToolType] lets the MCP SDK find this class as a container for tools when scanning the assembly.

Let’s add our first tool. Our AI is like John Snow - it knows nothing we do not provide. So it makes sense to give our AI application context about our companies' authorization model, so it knows what definitions and permissions exist.

In other words, our AI app should know our schema, that has all context needed in one place. So it is very easy to get this context by running one API-Call: GetSchema. Let’s implement it:

[McpServerToolType]
public static class SpiceDbTools
{
    [McpServerTool,
     Description(
         "Get the SpiceDB schema in use. When in doubt, use this first to get an overview over the existing model to make other calls.")]
    public static string GetSchema(
        SchemaService.SchemaServiceClient spiceDbClient)
    {
        try
        {
            var request = new ReadSchemaRequest();
            var response = spiceDbClient.ReadSchema(request);
            var schema = response.SchemaText;
            return schema;
        }
        catch (RpcException ex)
        {
            return $"Error looking up Schema: {ex.Status.Detail}";
        }
        catch (Exception ex)
        {
            return $"Error looking up Schema: {ex.Message}";
        }
    }
}

The actual code is pretty straightforward, a call to ReadSchema. Make sure to add the Attribute [McpServerTool] containing a good description, so the SDK finds the tool and the LLM knows what it’s for.

As next step, let’s directly integrate our first tool so we can try it out. We need to build our assembly once, so the SDK finds our provided tools and can expose them using MCP. Running

dotnet run -e SPICEDB_PSK=testkey

does the trick. You may directly stop the application afterwards (ctrl+c).

Integrate our MCP server into Claude Desktop

Our MCP Client Claude Desktop needs to know what MCP Servers exist to be able to use them. For this, we use a client-specific configuration file, the claude_desktop_config.json. If it doesn’t exist, it needs to be created in Claude’s configuration folder. On MacOS, the folder is located under ~/Library/Application\ Support/Claude/.

In this file, we add the following content:

{
    "mcpServers": {
        "spicedb": {
            "command": "dotnet",
            "args": [
                "run",
                "--project",
                "/path/to/solutionfolder",
                "--no-build"
            ],
            "env": {
                "SPICEDB_PSK": "testkey"
            }
        }
    }
}

This configuration tells Claude Desktop that there’s an MCP server called “spicedb”, that can be started by invoking dotnet run on the path the project resides. Change this path to your solution path, save the configuration file and (re-)start Claude, so our changes take effect.

Starting up our MCP Client and try it out the first time

With the configuration in place, we’re all set to ask Claude our first access-related question. Let’s ask it “Tell me something about my companies' authorization model”.

If you use Claude Desktop, you’ll see an approval workflow in place - on every MCP tool invocation, you have to allow your MCP Client to communicate with the tool.

User interface showing a query about an authorization model, with a dialog box prompting permissions for the 'spicedb' tool, including 'Allow' and 'Deny' options.
Approval workflow in Claude Desktop

As you can see in the picture, you can deny the LLMs request, allow it once, or for the lifetime of your whole chat.

Let’s allow our AI to talk to our tool and see what it can infer from our schema:

Screenshot of a chat explaining a company's authorization model with a SpiceDB schema snippet defining 'user' and 'team' entities, followed by a hierarchical structure summary including Users, Teams, Projects, and permissions ('contribute' and 'admin').
GetSchema MCP Server result

I omitted parts of the answer for readability, but I think you get the gist of it. Claude just gave us a comprehensive overview about the authorization structure in our company, all by doing one tool call to our MCP Server.

Congratulations! You just built your first MCP tool. It might actually be useful just by itself when you already use SpiceDB.

Adding LookupSubjects as our second tool

Let’s go ahead and add the LookupSubjects endpoint that lets us ask questions like “Who can read pay1?”

For that, we’ll add another tool implementation:

[McpServerTool,
 Description(
	 "Look up subjects with permission on a resource in SpiceDB. Answers questions like 'Who has permission on resource <x>?' e.g. 'What users can read document a?'")]
public static async Task<string> LookupSubjects(
	PermissionsService.PermissionsServiceClient spiceDbClient,
	[Description("The resource type")] string resourceType,
	[Description("The resource ID")] string resourceId,
	[Description("The permission to check")]
	string permission,
	[Description("The subjectobjecttype to check")]
	string subjectObjectType)
{
	try
	{
		var request = new LookupSubjectsRequest
		{
			Resource = new ObjectReference
			{
				ObjectType = resourceType,
				ObjectId = resourceId
			},
			Permission = permission,
			SubjectObjectType = subjectObjectType,
			Consistency = new Consistency
			{
				MinimizeLatency = true
			}
		};

		var response = spiceDbClient.LookupSubjects(request);
		var subjects = new List<string>();

		await foreach (var result in response.ResponseStream.ReadAllAsync())
		{
			var subject = result.Subject.SubjectObjectId;
			subjects.Add($"{subject}");
		}

		if (subjects.Count == 0)
		{
			return $"No subjects found with {permission} permission on {resourceType}:{resourceId}.";
		}

		return $"Subjects with '{permission}' permission on {resourceType}:{resourceId}:\n" +
			   string.Join("\n", subjects);
	}
	catch (RpcException ex)
	{
		return $"Error looking up subjects: {ex.Status.Detail}";
	}
	catch (Exception ex)
	{
		return $"Error looking up subjects: {ex.Message}";
	}
}

The call to the LookupSubjects endpoint answers this question, but it needs some parameters, which we define as method parameters with a good description. The resourceType and resourceId in this case would be document:pay1 and the subjectobjecttype would likely be user.

Likely? Yes, likely. If you look closely at the question, it is actually a very vague question for a machine to understand. No resourceType given, just “a normal question” anyone would ask. It has a lot of implicit context, like:

Now we are ready to try out the next iteration and see if our MCP Client can interpolate vague requirements. Don’t forget to rebuild the assembly. Otherwise Claude won’t find the new tool.

We restart Claude and check what our AI does when given the question we defined above. Here’s my result:

Screenshot of a query asking 'Who can read pay1?' and the corresponding permissions check, showing five users with read/view permissions on the resource 'pay1'.
Result of our second tool invocation using LookupSubjects

As we can see in the picture, first it gets the schema to get context understanding. Then, it assumes pay1 is a document. This is more or less by chance, our LLM could also have assumed it to be a folder or a project.

On this invocation, it got “read” from the question and directly assumed a document, so one call to LookupSubjects suffices. Knowing the schema internals, it also uses the right view-Permission. Great!

You’re welcome to try it out with other questions, like “who can work with search?” - it may take some attempts for the MCP Client, but it will arrive at the right answer.

And there we are, having implemented our first MCP Server with two tools. Congratulations!

As I mentioned before, the other tools the SpiceDB MCP Server offers are omitted. You can find the full example with five tools in the SpiceDbTools.cs on GitHub.

The method to add more tools stays the same. Each tool needs the McpServerTool attribute, a good description(!) for method and parameters, and an underlying implementation.

Logging the communication

As we used Claude Desktop, to get a look at the communication between Claude as Client and the MCP server we created, we need to tail the logfiles Claude Desktop creates. On MacOS, they are located at:

To get a stream of both communication partners, you can tail the logs with the following command:

tail -n 20 -f ~/Library/Logs/Claude/mcp*.log

Learnings and Pitfalls to avoid

As we just saw how logging works, I want to talk a bit about my learnings and pitfalls while implementing the MCP Server.

My first learning was, that the MCP C# SDK is really bleeding edge. There were some pretty obvious symptoms:

dguhr            74801   ... .../dotnet run --project /Users/dguhr/git/learn/spicedb-mcp2 --no-build
dguhr            74798   ... .../dotnet run --project /Users/dguhr/git/learn/spicedb-mcp2 --no-build
dguhr            74752   ... .../dotnet run --project /Users/dguhr/git/learn/spicedb-mcp2 --no-build
dguhr            74749   ... .../dotnet run --project /Users/dguhr/git/learn/spicedb-mcp2 --no-build
dguhr            73403   ... .../dotnet run --project /Users/dguhr/git/dguhr/SpiceDB-MCP/SpiceDB-MCP --no-build
dguhr            73400   ... .../dotnet run --project /Users/dguhr/git/dguhr/SpiceDB-MCP/SpiceDB-MCP --no-build
dguhr            72804   ... .../dotnet run --project /Users/dguhr/git/learn/spicedb-mcp2 --no-build
dguhr            72801   ... .../dotnet run --project /Users/dguhr/git/learn/spicedb-mcp2 --no-build
dguhr            72451   ... .../dotnet run --project /Users/dguhr/git/learn/spicedb-mcp2 --no-build
dguhr            72449   ... .../dotnet run --project /Users/dguhr/git/learn/spicedb-mcp2 --no-build
dguhr            71870   ... .../dotnet run --project /Users/dguhr/git/dguhr/SpiceDB-MCP/SpiceDB-MCP --no-build
dguhr            71865   ... .../dotnet run --project /Users/dguhr/git/dguhr/SpiceDB-MCP/SpiceDB-MCP --no-build

So, the spawned processes by Claude are not terminated currently. I raised an Issue on the SDKs GitHub project, and as per the comment I received, it seems Claude is not adhering to the MCP spec here. Nevertheless, there’s an already merged PR that should fix this behaviour in an upcoming SDK release.

Another pitfall is spec-compliant error handling, that has not made its way yet into the C# SDK. The Spec defines an isError: true- Field that should be set in case of error. Naive (and lazy) me was expecting to be able to just let exceptions bubble up and the SDK doing the proper spec-compliant handling for me.

I teared down my SpiceDB environment, asked a question and looked at the log stream:

...
2025-04-01T10:40:28.153Z [spicedb] [info] Message from server: {"jsonrpc":"2.0","id":15,"result":{"content":[{"type":"text","text":" Error connecting to subchannel."}],"isError":false}}
...

The logs rendered my assumption false. That’s why there are so many error strings returned instead. I found this open issue in the SDK.

To be fair here, I knew already this was bleeding edge, and they answered all inquiries pretty fast, so all I want to say here is: Keep up the good work, you SDK devs. Way to go, but a good start! I’d personally add a good ol' Pokémon exception handler instead of the proposed solutions for error handling, but what do I know.

Last but not least, there were also some other pitfalls on the implementation level I didn’t foresee:

My thoughts around AI and MCP

So, there we are - we just created our first, actually kind of useful MCP server, and learned something about ReBAC and AI on the way. Great!

Now that we are done implementing, allow me to give you my take on AI and MCP in general.

As I said initially, I am more on the sceptic side when it comes to AI. It simulates thinking, but it does just correlate vectors under the hood. This problem does not go away with MCP - you still need to know, at least in general, if the Model talks bullsh*t to you or not. Then again, AI can be an excellent helper for people who know that and act accordingly. It helps me daily in finding new angles on problems, creating boilerplate code, and other things.

The indeterminism of AI itself makes it hard for me, coming from a more or less security-touching background, to see widespread benefits for AI in this area. Security needs to be 100% correct, and there are a lot of great (and open source) tools for that.

That said, 100% correctness and great security is not what I see daily in the real world. Far from it, it’s more likely to be somewhere between 0 and 80% from my experience. I would still refer to known, deterministic solutions in this area, but to stay real, that’s not what people are incentivised to do lately.

My thoughts on MCP security

Looking through the security lens specifically at MCP, I think it makes matters with AI even worse at this point.

Let me explain:

First of all, MCP is a huge paradigm shift in creating products. Traditionally, even with AI, you’d more or less know at design time - when thinking about features and creating the code, that is - what features will end up in your product. You’d build it, you’d ship your app, and it behaves as expected.

Now in comes MCP. MCP “apps” are shipped, and then users add tools to their MCP Client. So, at design time, you don’t know which tools will be added by your users (to a point), and definitely not how the Client AI wants to interconnect them. You can compare this to browser developers. They don’t know which websites users will visit at runtime.

On the one hand, this makes it very fascinating, as my dear colleague Erik tried to glimpse into in his LinkedIn post here - do we really, finally get to experience the API economy - just that it’s rebranded to MCP economy?

On the other hand, it’s heck scary for me. Without proper control, who knows what the LLM in the MCP Client will do with all those interfaces, or what the server will expose? At least for me, it has some serious Daniel Suarez vibes (Daemon/Freedom™ are great books):

We essentially give our MCP Clients potential access to sensitive files, databases, or services. What could possibly go wrong?

Hint: A whole lot of things.

So, to make MCP “production ready” and controllable, its usage should be secured, authorized with fine-grained authorization (if I were to build an MCP Marketplace currently, I’d definitely look into ReBAC-Systems like SpiceDB or openFGA), and auditable. Currently, the spec defines neither of those in an accurate precision or depth.

Apart from that, the MCP architecture introduces some well-known security perimeters. The host (where the clients live) and the servers (where the tools live) communicate through the Model Context Protocol. So here we are at the well-known protocol layer, where we could enforce security policies:

Apart from that, there are some security considerations listed at the modelcontextprotocol.io website, and this list is long. Comparing even the first point:

Implement proper authentication mechanisms

to reality, this is very vague, and not trivial. To me, the current list feels a bit like a “short brainstorming so we have something instead of nothing” at this point, which is understandable given the age of the spec.

But helpful? Not really. Unless you already know what the points imply - then it’s a starting point for initiatives without paved out paths - in other words, for a lot of work. I couldn’t find that list in the spec, so… way to go, I’d say.

Next, there are MCP Clients and Servers: The MCP Spec doesn’t define much about securing those currently. Again, I don’t mean to rant harshly, as it is a very new spec. But in my opinion, there are some things worth considering:

Apart from that, I suspect rate limiting for backend systems will get a huge rise in popularity, as MCP Clients don’t necessarily go the most efficient path - you might’ve noticed that running the SpiceDB-MCP already.

Last but not least, the protocol and tooling itself will have some flaws in its younger years. Just before I wanted to publish this article, this vulnerability was linked in our internal communications. Invariant discovered an MCP vulnerability called Tool Poisoning Attacks (TPAs). TPAs involve embedding malicious instructions within MCP tool descriptions, invisible to users but visible to the Client and its underlying LLM, that could lead to data exfiltration and unauthorized actions.

Attackers can as of now easily - just by writing a malicious description in natural language and a bit of system knowledge - manipulate MCP Clients using their MCP Server into accessing sensitive files and transmitting data, while hiding this from the Clients user.

Even the approval workflows won’t help much. The attack exploits the fact that LLMs in the MCP Client see the complete tool description, while users typically see simplified versions of the description, if any. It seems descriptions are even more important than I wrote earlier, hehe.

Let’s stop here. I’ll put my security goggles off, though there’d be more to say here, e.g. about the currently limited testing and debugging capabilities.

My gist is: MCP Servers are basically arbitrary code, from anywhere, executed by an AI orchestrator. Take good care and ask a specialist (a human one), if you really want to go near production with MCP applications right now. It may work out just well, but we are at the very early stages, so a lot of work lies ahead.

My thoughts on UX

Now, believe it or not, I still think the Model Context Protocol is a good idea, or at least a good first step, as it provides an open standard. So, what’s the good part?

For me, it is the user experience (not to be confused with the developer experience, which currently is also only starting to be good with more and more SDKs releasing). As with AI itself, you suddenly have a natural language frontend, and because the underlying models are very generic, it’s a very good one, internationalization included.

I remember some years ago spending weeks(!) on finding and adding intent alternatives to the AWS Alexa SDK, building a custom skill. Just to see it fail over and over in production, as the variety of human language patterns is just too huge to manually get a grip of.

Now with AI and MCP, the intent-discovery is basically a solved problem. That’s a huge step forward in accessibility for normal humans, and on the positive side, could open up all kinds of innovation.

Conclusion

MCP has potential. Stay curious, but with proper scepticism.

I do not dismiss the potential of AI and MCP. Especially MCP is really a step in the right direction.

There’s a long way to go, though. Currently, it has at least as big a potential that things go wrong. What’s missing is the maturity of an 18-year-old-whisky, so to speak - e.g. real-world examples that are production ready, and implement the right security patterns, defined in a concise and complete standard.

I know I didn’t discuss all dimensions here (oh hi, environmental impact), but this article grew long enough already. So in the end, a short advice, if I may: Stay curious! Try this stuff out, understand it, perhaps with the tool I’ve shown here, and please don’t hesitate to ping me with your thoughts.

If you would like to know more about access management beyond RBAC, feel free to consult these slides from my talk about these concepts on our 2024 technology day. Or ping me on LinkedIn, I am always happy to have a chat.

TAGS