English
  • mcp access control
  • mcp rbac
  • personal access token

Empower your business: Connect AI tools to your existing service with access control

Learn how to empower your business by securely connecting AI tools to your existing services using Personal Access Tokens and Model Context Protocol (MCP), with complete source code and practical examples.

Yijun
Yijun
Developer

Stop wasting weeks on user auth
Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.
Get started
Product screenshot

Welcome to the guide on connecting AI tools to your existing services with access control!

We'll explore how to make your existing services ready for AI tools, especially through integration with LLM (using Model Context Protocol)) and various AI agents, while addressing access control challenges.

Through this guide, you'll gain:

  • Seamless AI integration: Learn how to connect AI tools to your services, making your data and functionality available in AI environments
  • Enhanced API security: Improve your API interfaces to protect data and user privacy with effective access control
  • Personalized AI experience for your user: Create unique AI-assisted experiences for each user through Personal Access Tokens

We provide complete tutorial resources, COMPLETE DEMO PROJECT SOURCE CODE (FRONTEND, BACKEND, and MCP SERVER INCLUDED), and even practical guides to help you build AI-ready services from scratch.

Here's how this guide can improve your business:

  • Competitive advantage: Enhance your service's technical capabilities and user experience to stand out in a competitive market
  • User value enhancement: Enable users to discover deeper value in your product through AI tools, increasing retention rates and satisfaction
  • Future-ready services: Seamlessly integrate your services with the AI ecosystem, preparing for the upcoming AI-driven business landscape and opening innovative growth paths

Let's get started!

What is MCP and how does it connect AI tools to your service

MCP (Model Context Protocol) is an open, universal protocol that standardizes how applications provide context information to large language models (LLMs).

MCP consists of several key components working together to enable AI tools to access your services:

In this guide, you only need to know that the MCP Server is the key connection point between your service and AI tools. It's responsible for providing a series of tools for the LLM to use, and these tools will interact with your own services. For more details about MCP, you can refer to What is MCP (Model Context Protocol) and how it works. Here, we'll focus only on the MCP Server.

We'll use a Content Management System (CMS) that has integrated Role-Based Access Control (RBAC) policies as our example. We'll create an MCP Server for it and define a get-available-article-count tool that allows the LLM to retrieve the number of articles available to the current user in the CMS:

This is the key code for connecting the MCP Server to your service. In this tool implementation, it sends a request to the service's api/articles endpoint and returns the result.

However, this is far from sufficient, because your service's API may not be public. Each endpoint needs access control, and different users can access different resources and data.

So next, we'll discuss how to add access control to your service.

How to implement access control for MCP server

It's important to understand that the users accessing your system through AI tools are the same individuals who might directly use your system - the MCP Server acts as their representative when they interact through AI tools.

So when users access your services through AI tools, two practical access control challenges arise:

  • How does the MCP Server login to your system like a user?
  • Should your system redesign its entire access control mechanism just to accommodate the MCP Server? This would be a significant cost and effort, especially when your original system already has its own authentication mechanism

The key to solving these problems is:

How users can let MCP Server to grant access from your service without using their credentials and interactive sign-in?

If you can solve this problem, you can directly interact with your service through the MCP Server, and your service can continue using the access control mechanism previously designed for users, without needing to redesign a new system just for the MCP Server!

But is this possible?

Of course it is! We can perfectly solve this problem by using Personal Access Tokens!

Personal access tokens (PATs) provide a secure way for users to grant access token without using their credentials and interactive sign-in. This is useful for CI/CD, scripts, or applications that need to access resources programmatically.

This is how the workflow looks like:

So, as long as your system supports Personal Access Tokens (PAT), you can perfectly solve the access control challenges between AI tools and your existing services without redesigning your authentication mechanisms, while ensuring data security and privacy protection for your users.

Now, let's see how to implement this in practice.

MCP server access control implementation

In this section, we'll implement access control for an MCP server using an existing CMS system as our foundation.

You can checkout the complete CMS sample tutorial and source code in RBAC in practice: Implementing secure authorization for your application, but this is not mandatory, we'll cover all the essential principles here.

The CMS sample is based on Logto, a popular open-source identity platform that provides a comprehensive authentication and authorization solution, but the technical implementation is not the focus of this article.

Design permission and access control policy for your service

The first step in implementing access control is designing permissions and access control policies for your system.

In our CMS example, we've designed the following API endpoints based on RBAC (Role-Based Access Control) and specified the permissions required to access each endpoint:

EndpointAccess control logic
GET /api/articles- Anyone with list:articles permission, OR authors can see their own articles
GET /api/articles/:id- Anyone with read:articles permission, OR author of the article
POST /api/articles- Anyone with create:articles permission
PATCH /api/articles/:id- Anyone with update:articles permission, OR author of the article
DELETE /api/articles/:id- Anyone with delete:articles permission, OR author of the article
PATCH /api/articles/:id/published- Only users with publish:articles permission

The system's permission design is as follows:

PermissionDescription
list:articlesView the list of all articles in the system
read:articlesRead any article's full content
create:articlesCreate new articles
update:articlesModify any article
delete:articlesDelete any article
publish:articlesChange publication status

Based on these permissions, we've defined the following roles for our CMS system:

Permission/RoleπŸ‘‘ AdminπŸ“ Publisher✍️ Author
DescriptionFull system access for complete content managementCan view all articles and control publication statusCan create new articles in the system
list:articlesβœ…βœ…βŒ
read:articlesβœ…βœ…βŒ
create:articlesβœ…βŒβœ…
update:articlesβœ…βŒβŒ
delete:articlesβœ…βŒβŒ
publish:articlesβœ…βœ…βŒ

Note: Authors automatically have read/update/delete permissions for their own articles, regardless of role permissions.

Next, we'll assign roles to users in our system (using the CMS demo as an example):

UserRole
AlexAdmin
BobPublisher
CharlieAuthor

And in Logto, as mentioned in the RBAC in practice article above, we've set up roles for our users.

Logto roles

Apply the access control policy to your service API

Here's how users log in to our CMS sample:

So, applying access control to your service API is as simple as adding a middleware to validate the access token and check the permissions in the step 9.

The core implementation is as follows (checkout the complete implementation in RBAC sample - backend):

And apply the middleware to the API endpoints that require authentication:

We have now added access control to our CMS system and assigned roles to our users.

After users log in and get their Access Token for the CMS API, they can use this token to access the CMS API. The Access Token contains the user's permission information. This lets us control what data to return based on user permissions.

Our next step is to implement the MCP Server to use Personal Access Tokens.

Understanding how Personal Access Token represents users

Refer to the CMS auth flow above, users get an Access Token for the CMS API after logging in. This Access Token is their credential for accessing the CMS API.

We just need to get an Access Token similar to what users get after login. Then we can use it to access the CMS API.

This is where Personal Access Tokens come in. They help us get the same kind of Access Token that users normally get after logging in.

Here's what we need to do:

  1. Create a Personal Access Token for a user
  2. Use this Personal Access Token to request an exchange token from the Auth Service's token endpoint. This gives us an Access Token like the one users get after logging in
  3. Use this Access Token in our MCP Service tool to access the CMS API

In this example, we use Logto for demonstration, since Logto supports Personal Access Tokens and token exchange. If you're not using Logto, you can follow this approach to implement your own Personal Access Token support.

Create Personal Access Token for your user

In Logto Console > User management, you can create a Personal Access Token for a user from their details page:

Create Personal Access Token in Logto Console

When creating a Personal Access Token, you can set its expiration time as needed.

Using Personal Access Token in MCP server

Now that we have the user's Personal Access Token, we can use it in our MCP Server.

First, let's follow Logto's Personal Access Token documentation, we'll get an Access Token for accessing the CMS API from Logto's token endpoint. You can checkout the complete source code here.

In the MCP Server, we use the Access Token from the exchangeAccessToken function to get data from the CMS API.

This way, the MCP Server doesn't need user login credentials to access the CMS API. Instead, it uses the user's Personal Access Token.

You can find the complete code in RBAC sample - mcp-server。

To learn how to deploy this MCP Server locally with Claude Desktop, check out the:MCP Server deployment guide。

You can also deploy this Server to various AI IDEs like Cursor, Cline, Windsurf, etc.

Test the access control

Let's test this implementation in Claude Desktop.

In our CMS, both Alex and Charles have created one article each.

Since Alex has the Admin role, they can see all articles. Charles, being an Author, can only see their own articles.

When we ask Claude how many available articles there are, Claude will use the get-available-article-count tool and ask for our permission:

Ask to use the tool

When we use Alex's Personal Access Token in MCP and ask Claude about the number of available articles, Claude calls the get-available-article-count tool and tells us there are 2 articles.

Answer for Alex

When we switch to Charles's Personal Access Token and ask the same question, Claude tells us there is only 1 article.

Answer for Charles

Awesome! We've successfully used Personal Access Tokens to access the CMS API and get the correct data.

This is exactly what we wanted: we create a Personal Access Token for each user, and when users configure their MCP Server with their token, we create a personalized AI experience for them.

Let me help you write the Summary section:

Summary

In this guide, we've explored how to connect AI tools to your existing services while maintaining proper access control. We demonstrated this using a CMS system with RBAC implementation, showing how Personal Access Tokens (PATs) can elegantly solve the authentication challenges.

You can find the complete source code for this implementation in our RBAC sample repository, which includes the CMS backend, frontend, and MCP server implementation.

When distributing your MCP server to users, remember to make the Personal Access Token configurable. This allows each user to:

  • Configure their own PAT in the MCP server
  • Access resources based on their specific permissions
  • Get personalized AI experiences that reflect their role and access levels

This approach ensures that your AI integration remains secure while providing a customized experience for each user based on their permissions and role in your system.

Wishing you tremendous success in your business as you embark on this AI integration journey! May your services thrive and grow with these new AI capabilities! πŸš€