Securing MCP Workflows: Dynamic Agentic AI Access Control

Key Points: 

1. MCP now includes OAuth 2.1 authentication in the June 2025 specification, addressing some early security gaps.
2. However, robust identity and access controls still require additional solutions beyond the base protocol.
3. Britive can help add security to existing MCP deployments by eliminating hard-coded creds and static access 
4. 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. 

Security Evolution: From Gaps to OAuth 2.1

While this openness and flexibility is very powerful, the early incarnation of the MCP specification left out many crucial security mechanism. The June 2025 specification update represents an important step forward by introducing OAuth 2.1 authentication support, making MCP servers act as OAuth 2.1 resource servers capable of accepting and responding to protected resource requests using access tokens.

This is a substantial improvement over the initial specification, which lacked basic identity and access management such as secure authentication or authorization mechanisms. Authorization servers must now implement OAuth 2.1 with appropriate security measures for both confidential and public clients, and MCP clients must use OAuth 2.0 Protected Resource Metadata for authorization server discovery. 

However, even with these important security enhancements, challenges remain. The OAuth 2.1 implementation primarily addresses authentication and basic authorization, yet there remain crucial identity and access control challenges inherent in agentic workflows. 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 the remaining security gaps today? 

Start With the Basics: Remove Hardcoded Credentials 

How Britive can secure MCP deployments 

Perhaps the lowest hanging fruit is static credentials. While the new OAuth 2.1 support provides a standardized authentication mechanism, many deployments still rely on hardcoded credentials during development and experimentation phases. MCP clients need to know which MCP servers they have access to and how to connect. This is often done via configuration files that may contain embedded credentials or tokens. Additionally, until all MCP clients and servers being used are upgraded and compliant with the latest MCP specification, older versions will continue to use insecure, hard-coded authentication methods.

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. For example, with 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 by providing a “bridge” solution to the new OAuth 2.1 authentication framework.

Agentic Access and Privileges Challenges

Over-provisioned, static access is rampant 

Once you have secured authentication through OAuth 2.1 and eliminated static credentials from your MCP workflow, the next major challenge is the access AI agents have to data and resources. While the June 2025 specification addresses authentication, it still leaves fine-grained access controls largely up to the implementation. As of this writing, the privileges granted via the OAuth authentication are essentially fixed at time of token creation and cannot dynamically change based on the actual access need. Which agents can access what data and in what context 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. Even with OAuth 2.1 in place, 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 OAuth tokens with the same broad privileges is now very high. Nothing in the current MCP specification 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 (especially ones that already support OAuth 2.1). 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 OAuth token and associated 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 — even if they support OAuth 2.1 for MCP workflows.

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. The June 2025 specification update with OAuth 2.1 support represents important progress in addressing security concerns, but it's still a rapidly evolving technology whose use and specification are running ahead of complete security best-practices. 

The addition of standardized authentication is a crucial step forward, but challenges around granular access control, privilege management, and zero standing privileges remain. 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 beyond the base OAuth 2.1 implementation, 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 checks it back in. What human would be that careful and disciplined?