RBAC for MCP inbound connections?

​@Uzumaki At this time, we do not have RBAC for MCP inbound connections.

I wonder if you can tailor the MCP calls from the LLM to send the username or some access-level identifier. Since that data goes to a task bot/API task, you could decide what to do based on that username/identifier. If the identifier is missing, just do nothing. 

Just a thought since I don’t believe there is a way to get the LLM to send logged-in user information automatically. The protocol itself wasn’t designed to send authentication information.

Glad the videos were helpful! I work hard on each one.

I like that idea of having some level of username/identifier build into to the tasks bots themselves. I will experiment with similar ideas. Hopefully this is something that Automation Anywhere expands on in the future.

And good job on the videos. Definitely made it easy to get started.

​@Aaron.Gleason Is it possible to retrieve user info when an MCP request is made? Say if a person triggers an automation via an SSO co-pilot chat and assuming my organization has a microsoft azure tenant, would that MCP request include that person’s user information?

@Aaron.Gleason Is it possible to retrieve user info when an MCP request is made? Say if a person triggers an automation via an SSO co-pilot chat and assuming my organization has a microsoft azure tenant, would that MCP request include that person’s user information?

​@Uzumaki This would depend on the sender of the MCP message to retrieve the authentication information and integrate it into the MCP message. As Automation Anywhere is the receiver in this case, we have no way to receive and process data that isn’t present in the MCP message.

​@Aaron.Gleason 

What do you mean by the sender integrates that information? In my case I’m using co-pilot studio, so I’m assuming that is the sender. Would that tool be need to be configured to send user ID information as part of the MCP message? And if so, how would I retrieve that from the AA side?

​@Uzumaki Ah, there’s the issue. If Co-Pilot Studio knows the basic profile context, they may be able to give you things like the user’s name, position within the company, manager, location, etc. Otherwise, it’s up to Co-Pilot Studio to get the ID information and make that part of the MCP message. 

Once it’s part of the MCP message, the tool you build on the AA side can extract the data in whatever node(s) you have the LLM put the user information into the message.

In the MCP/Co-Pilot video, I have a tool called “Search_For_Customer”. It has two inputs: sFirstName and sLastName. You would have to add additional inputs, such as sUserName, for the AA tool to receive that information. Note that the API_KEY/USER_NAME values can be different than the authenticated user, so that’s why the LLM has to put the authenticated user information into the MCP message.

​@Uzumaki Follow up: 

Apparently there are system variables in Co-Pilot Studio that expose user info:

• System.User.Id
• System.User.DisplayName
• System.User.Email

These will only work if the authentication is configured through AD, Entra ID, or SSO.

Take those values and put them into variables:

• varUserId = System.User.Id
• varUserName = System.User.DisplayName
• varUserEmail = System.User.Email

​@Aaron.Gleason 

To make sure I’m understanding, I would essentially have sAzureUserName or something similar be an input variable for whatever task bot so that the bot can handle the validation. And co-pilot studio is configured to grab the current user’s azure ID and pass that as part of the MCP message?

That all sounds good. Although, couldn’t the person making the co-pilot request just provide someone else’s username as part of the prompt and the LLM would then have to determine which username, the one from azure of the one coming from the prompt, to send to the bot?

​@Uzumaki That’s something you will have to test. I would think the LLM would reply with the correct variable if told to do so. If that can be overridden by a prompt, there’s not much that can be done about it. At that point, MCP might not be your best bet. Instead, stick within the AA infrastructure where we can authenticate users and make outbound LLM calls.