Agentic AI Security Blueprints
Security Guardrails for Enterprise AI Agents and MCP Tools
1. Introduction
The key characteristics of agentic AI systems are their autonomy and reasoning prowess that allow them to decompose complex tasks into smaller executable tasks, and then orchestrate their execution in a way that can monitor, reflect, and adapt / self-correct the execution as and when needed. Given this,
agentic AI has the potential to disrupt almost every business process prevalent in an enterprise today.
So we can basically agentify everything from a customer service desk, to industrial processes, e.g., HVAC optimization; to even leveraging agents to build the underlying software, data, and ML engineering pipelines. To enable this agentification process, we need a new holistic discipline that covers the full agentic lifecycle (Fig. 1):
from capturing the agentic use-case requirements
to designing the agents (what does a good agent hierarchy look like?, what are the applicable agentic skills & tools?)
to their secure & scalable implementation on an agentic platform
to the governance and maintenance of those agents.
Some principles to keep in mind during this agentification process:
The tendency is often to map manual processes 1-to-1 to agentic ones. This is an inefficient mapping. Designers should keep in mind that an agent is not, e.g., bound by HR processes :) So a software agent can do different things, and do it differently than a human.
At the same time, just like humans are the weakest link in the chain from a security perspective, a single agent can break the whole execution. So there are no exceptions and we also would not know whom to blame, fine, fire, etc. if an agent went rogue. So the recommendation is to design all agents with the same utmost care, together with logging, observability, and responsible AI guardrails.
Today, AI agents are exposed via ad-hoc endpoints, leading to fragmented security, operational, and compliance controls.
Without a well-architected agentic security architecture, we risk:
Security vulnerabilities: due to inconsistent authentication and authorization implementation;
Operational inefficiencies: from fragmented monitoring and telemetry;
Compliance risks: from insufficient audit trails and unauthorized data access / data governance;
Scalability challenges: without centralized (policy based) rate limiting and throttling;
Poor user experience (UX): from lack of standardized agent (tool and model) discovery, invocation patterns, and user access control.
In this article, we deep dive into security aspects of the agentic lifecycle. More specifically, we define the security patterns for standardized and scalable interactions between:
users → applications → agents → tools → (data) source systems.
2. Agentic AI Reference Architecture
Fig. 2 illustrates the key components of an agentic AI platform that forms the basis of the security patterns outlined in Section 3:
Reasoning layer: to decompose complex tasks and adapt their execution to achieve the given objective;
Agentic marketplace / registry: of existing and available agents, tools, and models;
Orchestration module: to orchestrate and monitor (observe) the execution of multi-agent systems;
Integration module: MCP tools to integrate with enterprise systems, e.g., ERP, CRM, KB repositories;
Shared memory management for data and context sharing among agents;
Governance layer, including explainability, privacy, security, safety guardrails, etc.
Given a user task, the goal of the agentic AI platform is to identify (compose) an agent (group of agents) capable to executing the given task. So the first component we need is a reasoning module capable of decomposing a task into sub-tasks, with execution of the respective agents orchestrated by an orchestration engine.
Chain of Thought (CoT) is the most widely used decomposition framework today to transform complex tasks into multiple manageable tasks and shed light into an interpretation of the model’s thinking process. Further, the ReAct (reasoning and acting) framework allows an agent to critically evaluate its own actions and outputs, learn from them, and subsequently refine its plan / reasoning process.
Agent composition implies the existence of an agent marketplace / registry of agents — with a well-defined description of the agent capabilities and constraints. For example, the Agent2Agent (A2A) protocol specifies the notion of an Agent Card (a JSON document) that serves as a digital “business card” for agents. It includes the following key information:
Identity: name, description, provider information.
Service Endpoint: The url where the A2A service can be reached.
A2A Capabilities: Supported protocol features like streaming or pushNotifications.
Authentication: Required authentication schemes (e.g., “Bearer”, “OAuth2”) to interact with the agent.
Skills: A list of specific tasks or functions the agent can perform (AgentSkill objects), including their id, name, description, inputModes, outputModes, and examples.Given the need to orchestrate multiple agents, there is a need for a system integration layer supporting different agent interaction patterns, e.g., agent-to-agent API, agent API providing output for human consumption, human triggering an AI agent, AI agent-to-agent with human in the Loop. The integration patterns need to be supported by the underlying Agent OS platform.
We refer to the model context protocol (MCP) proposed by Anthropic recently to connect AI agents to external systems / tools where enterprise data resides. Referred to as the “USB-C” for AI models, MCP enables interoperability using three main building blocks:
Resources: This is structured data that the server can give to the AI. For example, code snippets, parts of a document, or database query results; anything that adds factual context.
Prompts: are pre-made instructions or templates that the server can provide. Think of saved prompts for summarizing text or generating code in a specific style.
Tools: refer to actual actions the AI can ask the server to perform. On the retrieval side, these include querying a database, searching the web, etc.
By standardizing these, any AI system using MCP can understand how to request data (resources), provide instructions (prompts), or perform actions (tools) through any compatible MCP server.
Given the long-running nature of complex agents, memory management is key for agentic AI systems.
This entails both context sharing between tasks and maintaining execution context over long periods.
The standard approach here is to save the embedding representation of agent information into a vector store database that can support maximum inner product search (MIPS). For fast retrieval, the approximate nearest neighbors (ANN) algorithm is used that returns approximately top k-nearest neighbors with an accuracy trade-off versus a huge speed gain. Refer to my previous article on Long-term Memory for Agentic AI for a detailed discussion on this topic.
Finally, the governance layer. We need to ensure that data shared by the user specific to a task, or user profile data that cuts across tasks; is only shared with the relevant agents (table / report authentication and access control). Refer to my previous article on Responsible AI Agents for a discussion on the key dimensions needed to enable a well governed AI agent platform in terms of hallucination guardrails, data quality, privacy, reproducibility, explainability, human-in-the-loop (HITL), etc.
3. Security Patterns for Agentic Interactions
3.1 Applications to Agents
We first define the security pattern for user / application to agent interaction via an AI gateway. The end-to-end AI gateway based security architecture is illustrated in Fig. 3.
The security pattern consists of the following components:
Users and/or applications invoking the AI agents.
Marketplace: REST based registry for discovery of agents, tools and models, specifying capabilities, metadata, and endpoints.
AI gateway: API management (AMIP) layer enforcing security, routing, throttling, guardrails for all interactions.
IAM providers: we consider Entra ID for human users, and service principals (managed identities) for applications.
(While Entra ID is specific to Azure, equivalent IAM solutions on other platforms are equally applicable for the outlined security patterns.)Memory: maintains user session context and conversation state (for multi-turn conversations).
(Open)telemetry: centralized logging for monitoring, compliance and analytics.
