Agentic AI Security Patterns

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.

[embed]

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.

Fig. 1: Agentic AI lifecycle with focus on security patterns (Image by Author)

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.

Fig. 2: Agentic AI platform reference architecture (Image by Author)

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:

1. 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.
2. 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.
3. 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.

Fig. 3: AI gateway based agentic security architecture (Image by Author)

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.

Fig. 4: User (via application / UI) to agent security pattern (Image by Author)

The detailed user (via application / UI) to agent security flow is illustrated in Fig. 4, with the key steps outlined below:

1. User initiates interaction in the business application / UI.
2. App authenticates user with Entra ID using authorization code + PKCE (Proof Key for Code Exchange).
3. Entra ID issues a user access token to the app.
4. App invokes the AI gateway (APIM) with the user access token in header
5. AI gateway performs on-behalf-of (OBO) exchange with Entra ID to obtain a downstream agent token; aud (audience) = agent.
6. AI gateway validates tokens and enforces policies (JWT validation, with respect to agent scope / user role).
7. AI gateway forwards the request with validated context to the agent.
8. Agent authorizes the user at the agent level.
9. Agent performs business logic processing, and then returns the response to the user (via the application / UI).
10. Both AI gateway and agent log their timestamped invocation details to the OTel platform.

3.2 Agents to MCP Tools (MCP Server and Client)

In this section, we extend the previous user / application / UI to agent security pattern, to agent to tools interation (via MCP) to accommodate scenarios where an agent needs to invoke tools to fulfill its functionality.

In its simplest form, MCP client requests an OAuth 2.0 access token from an authorization server to subsequently call the MCP server API (with the issued access token). The OAuth 2.0 specification defines different flows on how to obtain an OAuth 2.0 access token from the authorization server. The most relevant flow here is: Token Exchange (TE).

This TE flow can be used by a MCP client to obtain a new access token from an authorization server in exchange of the incoming access token (obtained by an upstream system) on behalf of a user.

The TE flow is thus used when the MCP client runs on-behalf of (OBO) a user, serving near-real-time use cases.

In general, AI agents and MCP servers must not propagate access tokens received from upstream systems, to downstream systems; unless they are all deployed in the same runtime platform

token propagation must not cross application boundaries, esp. those residing in different security domains according to the OAuth 2.0 specification.

Note that in a long-running process without user-agent context, basically a batch process running in the background, the relevant security flow would be: Client Credential Grant (CCG).

The CCG is an OAuth 2.0 flow designed specifically for machine-to-machine (M2M) communication. It allows a backend application or automated service to securely authenticate and access resources directly on its own behalf, completely eliminating the need for any human user interaction. In this case,

the CCG flow is used by an MCP client (embedded within an AI agent — Fig. 2) to obtain a new access token from an authorization server based on its own (machine) identity.

Security flow: AI agent (MCP client) → MCP server → MCP tools API

With the above background, we outline the steps of a reference AI agent (MCP client) to MCP server interaction illustrated in Fig. 5:

Fig. 5: Security pattern focusing on the AI agent (MCP client) → MCP server → MCP tools API interaction part of the agentic lifecycle (Image by Author)

1. Agent is invoked by a user / application using an access token (sub-section 3.1). The incoming access token is explicitly for the agent, and cannot be used to invoke other agents or MCP servers. More specifically, the sub (subject) claim in the token identifies the original user. The aud (audience) claim identifies the agent as the intended recipient of the token. The token’s scope corresponds to only the permissions that the AI agent needs.
2. AI Agent needs to call a tool (the respective MCP server) to fulfill its functionality: The agent cannot just propagate the access token it received (from the user / application) to the MCP server for primarily two key reasons:

• Lineage: If propagated, the underlying tool (being called by the MCP server) wouldn’t know that the MCP server was the one making the call. It would look like the application made the call — breaking auditability.
• Scope: the received token may have a different scope of permissions than that needed by the MCP server. AI Agent thus performs a token exchange (TE): The agent makes a call to the auth server’s token endpoint with the following details: (own credentials, received access token, the new token’s scope and audience).

3. Authorization server validates the incoming request from the AI agent. If validated, it issues a new limited scope access token explicitly for the MCP server. The sub (subject) claim in the new token still identifies the original user — preserving the user context.
4. Agent invokes the MCP server: the exchanged access token in the request. As noted previously, with respect to the risks of token propagation, MCP server may perform another token exchange to invoke the downstream tools API, unless both are deployed in the same application / platform domain.

3.3 Data Retrieval from (downstream) Source Systems

In this section, we complete the agentic security lifecycle by focusing on the data retrieval aspect, when agents need to retrieve data from memory, structured, or unstructured data sources — refer to Fig. 3. (Agentic memory is also considered as a data storage platform, so similar security patterns apply.)

As you must have noted by now, the security pattern remains the same for token generation, validation, and exchange; with a token exchange needed as soon an interaction (between the MCP tool and storage platform in this case) crosses security domains. The end-to-end security pattern is illustrated in Fig. 6.

Fig. 6: End-to-end security pattern covering User →Application / UI → AI Agent → MCP Server / Tool → Data Platform (Image by Author)

4. Agentic Guardrails

We have so far primarily focused on agentic security from an authentication / authorization lens, and the proposed flows need to be integrated with guardrails to provide a more holistic risk management harness for enterprise AI use-cases.

Rather than creating a new list of agentic risks, I tried to consolidate the risks identified in the below two references:

1. OWASP whitepaper: Agentic AI — Threats and Mitigations, 2025.
2. IBM whitepaper: Accountability and Risk Matter in Agentic AI, 2025.

R1–15 refer to the risks identified in [1]. The ones in brackets () refer to the corresponding risks identified in [2]. R16: Persona-driven Bias, e.g., is quite interesting, which has been identified in [2], but is missing from [1].

• R1: Misaligned & Deceptive Behaviors (Dynamic Deception)
• R2: Intent Breaking & Goal Manipulation (Goal Misalignment)
• R3: Tool Misuse (Tool/ API Misuse)
• R4: Memory Poisoning (Agent Persistence)
• R5: Cascading Hallucination Attacks (Cascading System Attacks)

(Security Vulnerabilities)

• R6: Privilege Compromise
• R7: Identity Spoofing & Impersonation
• R8: Unexpected RCE & Code Attacks

(Operational Resilience)

• R9: Resource Overload
• R10: Repudiation & Untraceability

(Multi-agent Collusion)

• R11: Rogue Agents in Multi-agent Systems
• R12: Agent Communication Poisoning
• R13: Human Attacks on Multi-agent Systems

(Human Oversight)

• R14: Human Manipulation
• R15: Overwhelming Human in the Loop
• R16: (Persona-driven Bias)

The interesting part from a risk mitigation point of view is that their mitigation is often left to a central guardrails layer. However, this is not realistic and

the guardrails need to be specific to the underlying use-case, and implemented in their respective platform components / layers — which has a direct impact on the overall solution architecture.

The agentic AI component risk-architecture mapping is depicted in Fig. 7.

Fig. 7: Agentic AI risk mapping to platform architecture (Image by Author)

5. Conclusion

While the benefits of agentic AI systems are evident, they are also complex systems that are difficult to execute in a secure and scalable fashion. This is unfortunately a very challenging task given the non-deterministic and multi-layered architecture of agentic systems, encompassing users → applications → agents → tools → (data) source systems.

To overcome this, we outlined security patterns, architectural components, guardrails, and governance mechanisms — to provide security and compliance for the full agentic lifecycle.

Agentic AI security is still in its infancy, but becoming more critical by the day! As agents start performing longer tasks with memory, collaborate in multi-agentic scenarios with tools, and handle increasingly complex data workflows; the recommendation is to start early incorporating security by design based on zero-trust and security best principles — improving trust and accelerating enterprise adoption of agentic workflows.