Securing MCP Workflows: Dynamic Agentic AI Access Control

Key Points: 

1. MCP by itself doesn't provide necessary identity and access controls (it’s a work in progress) 
2. Britive can help add security to existing MCP deployments by eliminating hard-coded creds and static access 
3. We have our own MCP server that can provide granular, just-enough access for agentic workflows that goes beyond MCP and what any other vendor's MCP/AI solution offers 

If you spend any time reading tech news or on LinkedIn, it’s hard to avoid talk of AI agents or agentic AI. More recently, a new term has entered the conversation: MCP. It seems like MCP came out of nowhere and is now everywhere. So what is it, what is it good for, how does it fit in with AI agents, and most importantly, how secure is it? 

MCP stands for Model Context Protocol. It is an open standard that originated with Anthropic at the end of 2024. It is a way to simplify and standardize how LLMs access data and resources. There are MCP servers, which expose “tools” that let an LLM access data and services. For example, an MCP server for Hubspot might provide tools to read customer account details, update contact records, or create a new deal. MCP clients are the local component through which an LLM, AI agent, or similar tool like Claude Desktop accesses MCP servers. 

MCP makes it easier to build agents and complex workflows powered by an LLM. One of the biggest benefits is that it makes components interchangeable and interoperable, much like USB C or Bluetooth simplifies connecting different devices from different manufacturers with different capabilities. You can swap out one LLM model for another without having to rebuild other parts of your agentic workflow. MCP’s rapid adoption means it is increasingly likely that it will continue to play a crucial role for creating agentic systems composed of multiple AI agents communicating and performing tasks autonomously. 

While this openness and flexibility is very powerful, the early incarnation of the MCP specification leaves out many crucial security mechanisms (or it relies on other resources in an MCP workflow to implement them). For instance, the standard does not include basic identity and access management such as secure authentication or authorization mechanisms. There are efforts underway to address some of these limitations such as adopting OAuth for resource access authorization. However, these potential improvements are still in the proposal phase and may not offer all the flexibility needed for the multitude of emerging use cases for this technology. The reality is that MCP clients and servers are already seeing exponential real-world use including, increasingly, in corporate environments. So what can you do to address some of the security gaps today? 

Start With the Basics: Remove Hardcoded Credentials 

How Britive can secure MCP deployments 

Perhaps the lowest hanging fruit is static credentials. MCP clients need to know which MCP servers they have access to and how to connect. This is done via a JSON configuration file on the host that runs the MCP client, which is typically an end user’s computer. Many MCP servers provide access to resources that need authentication such as databases or SaaS applications. Credentials such as tokens or username and password are almost always hardcoded into the local MCP client configuration. 

To make matters worse, most users will use their own credentials for these resources since that is much easier than asking for separate, dedicated credentials for their AI agents—especially if they are experimenting on their own. There are already thousands of MCP servers for download, multiple freely available LLMs, and numerous other AI-enabled productivity tools like IDEs. It is very likely that employees in your organization are building agentic workflows to help them be more productive, efficient, or simply to understand this transformative technology. 

Figure 1: Typical MCP Client configuration for connecting to a MySQL MCP Server download from the internet

Britive makes it easy to solve the hardcoded credentials problem. You can use our powerful CLI tool PyBritive to replace static credentials with dynamic retrieval from the Britive platform. There are multiple ways to do this, and it works for virtually any application or data store accessed via an MCP server. For instance, you can embed a PyBritive call to fetch a set of short-lived credentials into memory. You can use it to retrieve credentials dynamically from Britive’s enterprise-grade secret vault. It is also easy to create simple scripts that perform dynamic actions. One example you see in the video is for MySQL. You can create a user, have Britive provision the user with a set of pre-approved permissions at runtime, and then remove the user when the agent’s task is done or after a policy-configured amount of time. 

Using Britive to eliminate (yet more) hardcoded, static credentials is a quick security win. It is also a low-friction, minimally disruptive solution that allows experimentation and innovation to keep moving forward quickly. 

Agentic Access and Privileges Challenges

Over-provisioned, static access is rampant 

Once you have eliminated static credentials from your MCP workflow, the next major challenge is the access AI agents have to data and resources. One of the biggest security shortcomings of the current MCP specification version is the lack of access controls. Which agents can access what data using which MCP server tools is entirely left up to the creator of the agentic workflow and the owner of the resource, respectively. 

This creates a more subtle challenge. The MCP servers expose every single tool an AI agent could use without knowing if a specific agent is allowed to use only a subset. The server will pass any agent’s request to use a tool along to its backing application and will simply pass through any error if the agent is denied due to lack of authorization. To complicate matters, AI agents, unlike typical automations such as CI/CD workers or service accounts, have non-deterministic behavior. The agent might use the same few tools for a given MCP server 95% of the time, then ask for a tool that other 5% which requires additional permissions. This means the identity associated with an agent will require the most access it could ever need, even if the majority of the time fewer privileges are needed to carry out its task. 

It gets worse. As discussed above, you cannot assume that users won’t try to use their own credentials for their agents. If a user happens to have a highly privileged account such as an application administrator, the risk of an agent using the same credentials is now very high. Nothing in MCP will prevent the agent from taking full advantage of its privileges, even if the user doesn’t ever intend for this. One wrong prompt could lead the agent to perform a destructive update or delete action when only reading data was intended. 

Providing an identity just-in-time (JIT) access—ideally with the least privileges necessary—and automatically removing that access entirely afterward for zero standing privileges (ZSP) is an existing identity and access management best practice. There is no reason agentic access should be any less secure. Multiple vendors are already offering solutions (or at least claiming solutions), but you must look carefully at what is being offered versus what a truly best-practices solution is. 

Perhaps the most common solution is by leveraging existing identity security tools. For example, some privileged access management (PAM) vendors are promoting using AI-specific identities or access profiles. This is a step in the right direction, but this 1:1 identity-to-policy model also suffers from the same over-privileged issue. The policy must provide the most privileges the agent could ever need, regardless of if the highest access levels are needed for a give task. Also, if the vendor is not providing JIT access or enabling ZSP via dynamic privilege creation or elevation in the target resource, you are adding additional risk by creating new static access for these agents. 

Another approach from identity security vendors is to offer their own MCP servers for common applications and data stores. This has the advantage of using only trusted, curated MCP servers which expose selected functionality as tools. It also allows for a tighter coupling between the MCP server’s capabilities and the access and policy controls in the vendor’s identity management platform. 

The downside is your users will be severely restricted to what the vendor can provide. Given the hyper-fast pace of MCP development, it is unlikely any one vendor can keep up with all the services desired. What’s more, this model only works if you can force the entire organization into this solution. The processes, employee policies, and network configurations to enforce this will be onerous. And depending on the vendor’s implementation, there still is no guarantee of JIT access, least-privilege access, or ZSP. 

Intelligent, Granular Access for Agentic Workflows

JIT with ZSP for AI agents with Britive’s MCP server 

Britive addresses these shortcomings by introducing our own MCP server. The Britive platform already delivers JIT, ephemeral access for true ZSP. Our granular access policies make it possible to provide the same identity with different sets of permissions to the same resource so only the least privileges necessary are temporarily granted. Britive was designed to manage access for non-human identities from the outset so AI agents can have unique identities or can act on behalf of existing human identities. Our MCP server takes advantage of the powerful reasoning and problem-solving capabilities of today’s LLMs. 

The video demonstrates the powerful combination of Britive’s platform and an agentic workflow facilitated via the MCP protocol. An LLM like Claude 4.0 is capable of understanding context. You can see this in action when it is asked to retrieve some data from Snowflake that would require read-only access. It requests to checkout a read-only access profile from Britive. Britive checks to see if the identity provided by the agent is authorized to access this profile. In this case it is, so Britive then temporarily grants its identity read-only access in Snowflake. 

Figure 2: Claude using MCP to request read-only Snowflake access through Britive 

This is the power of both Britive’s granular access profiles and MCP’s use of simple tools, described in plain language for LLMs to understand. Our MCP server exposes tools to see all access profiles an identity has and a tool to checkout that access. Claude uses the first tool to see its possible profiles. It then uses the context of the request (“read Snowflake data”) to checkout not just Snowflake access but the profile with the correct minimum level of access needed to complete its task. 

Figure 3: Britive's granular access profiles work seamlessly with MCP 

In our demonstration, a follow up request requires the agent to have more than read-only privileges. Here again the LLM is able to independently determine its current level of access is insufficient, go back to Britive to check out the proper profile with elevated access, then attempt its task again until complete. You can even see how the model reasons through the problem. It makes several attempts to get the requested data before making the decision to request additional access. 

Figure 4: Agent requesting additional privileges

Finally, it’s easy to clean up after the model completes its task. Checking in profiles ensures that there is no standing access. LLMs are smart enough to take such actions without needing to be explicitly told to do so. If the agent isn’t using a resource, there is no need for it to have any access to it. Without a true ZSP, JIT identity platform like Britive, this isn’t easy or even possible. MCP makes it simple for agents to do this autonomously. 

Closing Thoughts

MCP is a double-edged sword. It is a powerful enabler of agentic AI workflows and innovation. It is also a bleeding-edge technology whose use and specification are running well ahead of security best-practices. These risks don’t mean you must avoid it altogether. It means you must think carefully how you allow it to be used, how you secure it, and how you protect the resources and data at risk from improper agentic access.

Britive with MCP is a secure, flexible combination that lets you continue to innovate while reducing the identity and access risks inherent in this new technology. Plus, just think: an agent will check out its own least-privileged access and check it back in when it is no longer needed. What human would be that careful and disciplined?