This post is motivated by security aspect of agentic workflows growing rapidly and happen to access third party services/tools code from marketplaces to run in local machine. MCP (model context protocol) introduced by Anthropic and specified here https://github.com/modelcontextprotocol needs to be understood from security perspective. AI agents gain steam and can be used for variety of use cases. There is a growing marketplace for MCP servers for varied tools or services to be used by AI agent deployed by the user for dedicated tasks. In datacenter context, Agents can be useful for running server maintenance and monitoring tasks by running regressions, analyzing performance and power telemetry and creating alert events or create chat box to make user understand analysis of gathered telemetry. This can be very useful in summarizing analytics for large number of machines. Security is one aspect which may need to be taken care seriously for deploying such agents using external tools procured from marketplace. Purpose of this post is to discuss security of such accesses which may run code from third party in same machine accessed by MCP server and MCP client.
Before discussing security aspect, it may be essential to understand the model context protocol used by AI agents to connect to external services. In general three components in these interactions are:
- MCP client which is spawned by the AI agent deployed by user and it connects to MCP server using MCP which initiates interactions with so called services/tools APIs. Model context protocol utilizes JSON-RPC type transport mechanism (called stdio or SSE-server side) and HTTP type of requests.
- MCP server/servers (this can be local on same machine alongside LLM API’s access initiator in MCP client or it could be remote like web server) responsible for translating the MCP client requests into services requests like DB/FILE accesses or HTTP API requests to third party tools. In general, for real life tasks more than one MCP servers are invoked.
- And finally the third-party services accessed using APIs which could be cloud service (e.g: Github, Playwright, MongoDB, Spotify …) or the one chosen and accessed from marketplaces like https://mcp.so , https://glama.ai/mcp/servers or similar runs on local machine MCP server. Note the list of MCP servers offering varied services are growing very fast. As of this writing there are more than 10,000 such servers available for access of different type of services/tools on few prominent sites.
In general, MCP is form of remote procedure call used by clients in agentic framework which will spawn a server called MCP server here and this server might be local in your machine executing some foreign code fetched from a MCP server marketplace. It can cause a security breach of your machine memory and storage space used to store such code related pages accessed using third party API’s.
As of now MCP specification incorporates OAuth2.1 security flows which ensures:
- Users of AI agent can give some access to its data and define its scope of access.
- Agents use services or tools where MCP server requires agent to get access token on behalf of user, user needs to approve such permissions. These tokens are revocable and have a limited lifespan. These tokens are linked to user’s identity unlike API keys.
Steps can be outlined as follows or can be defined as a STATE MACHINE:
- Initiate service or tool request on MCP server by MCP client/LLM spawned in your local machine.
- If request was issued without token, MCP server rejects the request and calls it unauthorized. Its response includes guidance for authentication by including authorization URL.
- Client fetches metadata from authorization server given to it which has URL to send to user and exchange authorization code for token needed for access.
- MCP client retrieves the meta-data from this included URL by doing meta-data JSON lookup
- MCP client directs the user to authorization end point, user than logins and grant consent which is given after user has seen the requesting app and associated scope of its access.
- Finally, authorization server redirects the user browser to URI, MCP client is running a local web browser which listens to this URI and receives the code securely. This code is single use and short-lived representing user authorization. Token is still not there as yet for access of resource like tool from mcp server.
- Finally, MCP client sends request to token end point exchanging the authorization code for token. Token end point verifies the authorization code to ascertain that same client is exchanging code for token who initiated this flow in first place. On validation, it issues access token along with optional refresh token to provide offline access scope.
- After step-7, agent is capable of making authorized internal access calls to MCP server by including authorization header. MCP clients can interact with MCP server until token expiration time.
Above is simplified version of flow and needs more details to be complete, Note during step-8 in order for MCP server to satisfy the MCP client access, it needs to call third party APIs on behalf of user, it does not use same token rather it may use separate upstream token to call these API’s (not part of MCP specification as of now), basically server acts as resource to MCP client and acts as client to third party APIs. Note MCP specification does not cover the third-party API access. It is obvious that mechanisms are needed to test resilience against prompt injection, ambiguous instructions, and privilege escalation attempts in these third-party API access.
This post does not discuss MCP server implementation choices which may open new possibilities.
One such proposition is designing an MCP (Model Context Protocol) gateway with Task-Based Access Control (TBAC) and On-Behalf-Of (OBO) authentication to ensure robust and dynamic security for AI agents access to these tools. MCP gateway’s job is to forward the Authorization header with the user’s token to the upstream MCP server, which handles the OBO token exchange with the identity provider. This enables consistent permission boundaries and least-privilege access throughout multi-hop agent chains. Policies can be enforced directly at the gateway, leveraging JSON web tokens and attributes from each MCP request. Policies can filter, allow, or deny access to specific tools, tasks, or transaction-level parameters. Checks can be incorporated to allow minimum required permissions per context (for example “Agent may use Email API only if email recipient is internal”). There are other possible solutions like ensuring every tool call, task, and data access is contextually and cryptographically authorized.
Basic idea of this post was to explore the security aspect of deploying Agentic framework gaining momentum rapidly using MCP as a means to access external services. This deployment of agents could be security risk if deployed in most critical and vulnerable part of data center infrastructure like configuration management or telemetry analytics. Currently outlined solutions need rigorous frameworks for security for rapid adoption.