Your Architecture vs. AI Agents: Can MCP Hold the Line?

Inspiration Acknowledgment

This white paper was deeply inspired by a diagram shared by Rakesh Gohel on LinkedIn, titled “What people think AI agents are vs. What AI Agents actually are.” His visualization clearly captures the gap between public perception and the technical complexity of AI agents. It served as a crucial foundation for structuring this paper and framing the core problem statement. The referenced content is summarized in Appendix. Our sincere thanks to Rakesh Gohel for the insight and inspiration.

Rakesh Gohel on LinkedIn: https://www.linkedin.com/in/rakeshgohel01/

[Figure 1] What AI Agent actually are

1. The Line Between Roles and Responsibilities

The MCP server and AI agent are both core components in any AI-driven system. While they operate collaboratively within a unified execution flow, their purpose and responsibilities are fundamentally distinct. In practice, however, these roles are often misunderstood or conflated, leading to architectural flaws, over-permissioned agents, and execution control failures[1]. This confusion goes beyond a simple misunderstanding of system structure. It can result in unchecked expansion of execution authority, policy circumvention, and non-auditable user actions—all of which pose direct and significant security risks.

For instance, when an AI agent is designed not just to interpret user intent but to directly invoke external systems, it introduces unpredictable behaviors driven by LLM non-determinism. Worse, such actions might bypass policy controls and access unauthorized resources. Conversely, if an MCP server is tasked with interpreting user intent or making policy decisions, it creates a structural mismatch in decision responsibility. This results in overly centralized control, undermining both auditability and explainability of execution decisions.

This section provides a clear separation of responsibilities between MCP servers and AI agents. It defines the functional boundaries and operational limits of each component to prevent misalignment and ensure secure, explainable system design.

What Is the MCP Server?

The MCP (Model Context Protocol) server is a backend interface layer that connects AI agents to external resources and systems, enabling them to perform tasks. It acts as a bridge between agents and various systems—APIs, databases, SaaS platforms—by abstracting those resources in a standardized format[2]. Functionally, the MCP server behaves like a unified gateway, allowing AI agents to initiate operations without needing to know the implementation details of the target systems.

However, the MCP server is not a full security controller. While it may offer basic routing and interfacing, it only provides limited support for policy evaluation, execution control, and session auditing. In practice, many of these capabilities are implemented through complementary security layers depending on system requirements[26].

[Figure 2] MCP Server Structure

Core Responsibility Structure

• Tool Proxying and Resource Routing: MCP exposes external tools (e.g., APIs, databases, files) through a standardized interface. It acts as a proxy, converting abstract agent requests into real system calls.

• Policy Enforcement: MCP handles authentication and basic authorization. However, fine-grained, context-aware policy evaluation (such as PBAC or ABAC) typically requires external enforcement mechanisms[3].

• Context Management: MCP can work with external context stores to manage user sessions, conversation history, or user preferences—contributing to consistent contextual awareness.

• Task Orchestration and Flow Control: It can deconstruct and orchestrate abstract agent requests into multiple system calls. Advanced control flows—like conditional branching or approval steps—are often handled by separate orchestration components.

• Execution Control and Auditing: The MCP server may support logging, error handling, and failure response. However, recording the reason for policy denial or approval traceability is considered an optional, extendable feature.

In summary, the MCP server is a platform optimized for resource abstraction and execution connectivity, but it does not handle policy judgment or direct enforcement. When necessary, it can be paired with dedicated security layers for enforcement and audit logging.

What Is an AI Agent?

An AI agent is an intelligent interface layer that interacts directly with users, interprets natural language instructions, and generates execution plans. It is typically powered by LLMs (Large Language Models), which enable it to understand the context of user requests and determine the appropriate system calls needed to fulfill them[4].

Core Functions

• Intent Interpretation: Analyzes natural language queries or commands to extract the user’s underlying intent.

• Plan Generation: Constructs a step-by-step execution plan to achieve the intended outcome.

• MCP Interface Invocation: If external system access is required, the agent calls the MCP API to indirectly interact with the necessary resources[2].

• Short-Term Memory & Inference Handling: Maintains temporary session context or conversation history for improved reasoning during active tasks.

• Response Generation: Delivers results back to the user in natural language or guides them toward the next step.

The AI agent is responsible for understanding and planning—acting as the “brain” of the system. However, actual execution should occur through the MCP server, ensuring that system calls remain governed and abstracted.

[Figure 3] AI Agent Flow

Clarifying the Distinction

Summary of Role Separation

• The AI agent acts as the “brain”, interpreting user intent and generating execution plans.

• The MCP server acts as the “arms and legs”, safely executing the defined tasks[5].

This separation allows the system to maintain both intelligence and control—ensuring secure, scalable automation.

[Figure 4] Summary of Role Separation

Functional Separation Between AI Agent and MCP Server

The diagram below illustrates the role separation between the MCP server and the AI agent.

[Figure 5] Functional Separation Between AI Agent and MCP Server

Description:

When a user submits a request, the AI agent interprets the input and builds an execution plan. That plan is then handed off to the MCP server, which performs the actual task by interacting with external systems. This structure ensures clear responsibility boundaries, policy-governed execution, and scalable system design.

In the next section, we’ll explore how MCP and AI agents interact, and examine the architectural patterns used to implement these interfaces in real-world systems.

2. Usage Patterns and Interface Design

This section explores how the MCP server and AI agents are used in practice, and what kinds of interfaces they provide. Although both components operate within a shared execution flow, they interact with different parties and follow distinct communication paradigms. Understanding these differences is essential for proper system integration[6].

How the MCP Server Is Used

The MCP server is not used by end users, but rather by AI agents or system developers. Its typical usage includes the following patterns:

• API-Based Invocation: MCP servers expose REST or gRPC-based APIs. AI agents use these interfaces to submit task requests (e.g., /fetchData, /invokeService). These requests are typically formatted in JSON and include an authentication token[7].

• Policy-Based Request Evaluation: Upon receiving a request, the MCP evaluates whether to allow or deny execution based on policies such as PBAC or ABAC. This is often delegated to an internal policy engine (e.g., based on Cedar or OPA) that assesses the user, resource, and purpose[8].

• Tool/Data Brokering: Internally, the MCP is connected to enterprise systems such as APIs, databases, or cloud services. It relays requests on behalf of the AI agent and returns the responses.

• Session and Context Management: In some implementations, the MCP manages session identifiers or conversation context to provide consistent, state-aware responses.

Importantly, end users do not directly interact with the MCP server. All requests are proxied through AI agents or system-level components. The MCP functions strictly as a backend layer responsible for secure execution and enforcement.

How the AI Agent Is Used

AI agents are the primary user-facing components, directly accessed by users or external systems. They support a variety of interfaces:

• Conversational Interfaces (Chat/Voice): Users typically interact with agents using natural language. The agent interprets the input and responds accordingly. This is powered by LLMs or predefined skill sets[9].

• App/Web Integration: Agents can be embedded into applications through UI buttons, workflow triggers, or command boxes, allowing users to invoke them indirectly.

• API-Based Services: In some cases, the agent is deployed as a REST API or webhook-based service. External systems can directly send requests and receive structured responses, such as JSON.

• Business Logic Integration: After interpreting user input, the agent may invoke the MCP server to interact with external systems. It then uses the returned data to formulate a response or plan a follow-up action[10].

In short, the AI agent serves as the intelligent interface layer between users and systems—focusing on intent interpretation and planning—while the MCP server handles downstream execution and enforcement.

Structural Differences in Interface Design

The MCP server and AI agent are architected with fundamentally different interface patterns, as outlined below.

[Figure 6] Structural Differences in Interface Design

These structural differences serve as a critical design guideline for system architects. For example, security configurations should be centered around the MCP, while user interface enhancements should be addressed at the AI agent level.

3. Positioning Within the Overall System Architecture

As AI-driven systems become more complex, it is increasingly important to understand where and how MCP servers and AI agents fit within the broader architecture. For IT architects and decision-makers, this includes a clear grasp of how these components interact and how to define trust boundaries between them[12].

Position and Role of the MCP Server in the Architecture

The MCP server resides in the backend middleware layer and serves several core functions:

• Tool and Data Integration : It receives execution requests from AI agents and connects to various systems such as APIs, databases, and SaaS platforms.

• Policy-Governed Execution : While the MCP handles basic authentication and authorization, policy enforcement for API calls is typically delegated to a security extension layer, such as MCP Agent PAM (Privileged Access Management).

• Request Routing and Logging : It manages request flow and logs execution traces at a basic level.

Notably, advanced policy enforcement, deep audit logging, and user behavior analytics are not handled by the MCP server itself, but are extended through the MCP Agent PAM. This extension layer provides the following capabilities:

• ACL-Based Access Control Granular policies per resource and user context

• Policy-Based Filtering (PBAC) Conditional allow/deny logic based on request context

• Audit Logging and Session Traceability Full API request-response trails, including unauthorized attempts and exception handling[13]

• Data Loss Prevention (DLP) Detection of sensitive content, with options for masking or blocking output[14]

• User and Entity Behavior Analytics (UEBA) Anomaly detection for users or agents, with ML-based risk scoring[15]

These capabilities extend the MCP’s core functions, enabling stronger enforcement, greater reliability, and regulatory compliance within execution workflows.

Position and Role of the AI Agent in the Architecture

AI agents operate in the application or user interface layer. They receive user inputs and, when necessary, invoke LLM APIs for natural language understanding or submit API requests to the MCP server.

• User Input Processing Accepts various forms of input such as natural language, UI interactions, or chat messages

• Execution Planning Analyzes the request and determines the appropriate next steps

• Branching Logic

  • If response can be generated internally → Call LLM API
  • If external data is needed → Call MCP server

In this design, the AI agent acts as the entry point for intelligent reasoning and control, while actual execution and enforcement are handled by the MCP server and Agent PAM.

Interactions Within the Overall System

The following structure illustrates a typical architecture for an MCP-based AI system:

[Figure 7] Interactions Within the Overall System

In this flow, the AI agent intelligently interprets user-centric input, the MCP server connects that intent to appropriate backend resources, and the MCP Agent PAM enforces policies, monitors behaviors, and protects data across all execution paths.

This layered separation is more than a technical design—it enables a secure, auditable, and explainable AI system architecture by decoupling intent interpretation, execution control, and behavior monitoring. It provides the following practical advantages:

• Clear Separation of Policy Evaluation Flows : The AI agent is responsible only for interpreting and planning based on user intent. Execution accountability is entirely handled by the MCP server and Agent PAM, ensuring trust boundaries remain intact.

• Auditable Execution and Response Tracing : MCP Agent PAM logs every request and response in a structured format, enriched with policy context. This forms the foundation for post-incident analysis and compliance reporting.

• Integrated Data Protection and Behavior Monitoring : DLP and UEBA functions go beyond traditional security. They enforce sensitive data controls and detect anomalous patterns at runtime, protecting the execution flow itself.

• Foundation for Technical Explainability : Because decision-making and execution are clearly separated, each step is traceable and verifiable. This supports regulatory compliance and strengthens internal audit capabilities[27].

• Role-Based Security Architecture : This architecture supports not only scalability, but also Separation of Duties (SoD) and Zero Trust execution layers, making it well-suited for secure AI system operations[16][17][18].

4. Common Misconceptions and Clarifications

Even when the roles and architecture of the MCP server and AI agent are clearly defined, misuse and misunderstanding still occur frequently in practice. This section highlights three of the most common misconceptions, explains why they are problematic, and offers guidance on how to avoid them[19].

Misconception 1: “Can’t I just use the MCP server like an AI agent?”

The Misunderstanding

Some expect to send natural language commands directly to the MCP server and receive intelligent responses—effectively treating it like an AI agent. In practice, developers sometimes attempt to bypass the chatbot and send freeform requests directly to MCP APIs[20].

Why It’s a Problem

The MCP server is not designed to interpret natural language or understand user intent. It only processes structured API calls with valid authentication tokens. Sending unstructured requests leads to execution errors and potential bypass of security and policy enforcement mechanisms.

The Correct Perspective

Users should always interact through the AI agent, which interprets the natural language request and generates structured API calls to the MCP server[21].

[Figure 8] Structured API Calls to the MCP Server

Misconception 2: “The AI agent will handle security on its own, right?”

The Misunderstanding

Because AI agents behave intelligently, some assume they can call databases directly or handle execution policies autonomously.

Why It’s a Problem

AI agents—especially LLM-based—are inherently unpredictable and highly vulnerable to issues like prompt injection attacks[22]. They lack the consistency required to enforce security policies and cannot be centrally audited or governed.

The Correct Perspective

AI agents should only initiate predefined, restricted actions via the MCP server. All policy enforcement, access control, and logging should be handled by MCP Agent PAM, ensuring clear separation of control and accountability[23].

Misconception 3: “Can’t I just use one component and skip the other?”

The Misunderstanding

Some believe a system could be built with just an MCP server or just an AI agent. For example, they may propose allowing AI agents to call APIs or databases directly, or embedding basic AI logic into MCP to handle queries.

Why It’s a Problem

Assigning all responsibilities to one component breaks role separation, reduces flexibility, and increases maintenance burden. It leads to serious challenges in policy enforcement, error recovery, and cross-team collaboration[24][25].

The Correct Perspective

The two components must have clearly separated roles, with the ability to evolve independently while remaining integrated through a unified interface. The AI agent is responsible for understanding user context and defining intent, while the MCP server executes tasks based on that intent[25]. Security-related functions—such as access control, logging, DLP, and UEBA—are optional extensions and are typically handled by the MCP Agent PAM.

[Figure 9] Clearly Separated Roles for each component

Key Takeaways

5. Conclusion and Summary

This white paper has outlined how to design secure, scalable AI systems by clearly separating the roles and responsibilities of the MCP server and the AI agent. While real-world implementations often attempt to merge or confuse these components, doing so introduces long-term risks: security vulnerabilities, policy enforcement failures, and unclear execution accountability.

Summary: Why Structural Separation Matters

• The AI agent should focus on interpretation and planning : Understanding user intent and breaking it down into executable tasks should remain the sole responsibility of the intelligent interface layer.

• The MCP server should focus on execution and integration : Safe resource invocation, request routing, and policy application must be centralized within the MCP server, separate from the decision-making logic.

• The MCP Agent PAM should extend the execution layer with control and oversight : Before any AI-generated request is executed, it must be evaluated against policies, inspected for sensitive data, and monitored for anomalous behavior—all in real time[11][19].

Practical Design Considerations

1. Interfaces must be explicitly separated and flows clearly defined. AI agents and the MCP server should interact through distinct API layers, and LLM APIs must be handled separately from MCP APIs.

2. All execution requests must be routed through the MCP server. Any request involving database access, external SaaS integration, or system modification must be centrally controlled via the MCP server. Direct execution by the AI agent must be strictly prohibited.

3. The MCP Agent PAM is not an optional layer—it is a mandatory security infrastructure. It provides critical enforcement in the following areas:

• Policy-Based Conditional Evaluation (PBAC, ABAC, RBAC, ReBAC)
• Behavior-Based Execution Control using UEBA
• Sensitive Data Protection through DLP
• Full Audit Logging of Execution Flows (Request-to-Response Tracing)

If execution control is omitted and AI agents are allowed to call system APIs directly, several high-risk security scenarios may occur:

• Unpredictable LLM outputs may trigger direct execution, bypassing policies and misusing permissions

• Execution flows may go unaudited, resulting in missing logs and inadequate incident response

• Sensitive data exposure or anomalous behavior may go undetected, increasing the risk of internal compromise

The PAM layer should not be seen as a "nice-to-have" security enhancement—it must be regarded as core infrastructure for execution safety and visibility.

4. Every layer in the flow must also support explainability. The path from request → policy evaluation → execution → response → audit logging must be structured and traceable, forming the foundation not only for regulatory compliance but also for operational transparency[20].

Final Thoughts

As AI agents become more advanced and LLM APIs gain greater autonomy, systems must adopt a structure that ensures:

• A clear attribution of who executed what, systemically and reliably

• A policy-based explanation of why it was allowed, under which conditions

• A verifiable audit trail of whether the execution followed the correct flow, using logs and session-level tracing

This is made possible by the separation of the AI agent and MCP server, combined with the integration of MCP Agent PAM as an execution control layer.

Designing AI-first systems is no longer about basic integration—it now demands an architecture rooted in clear responsibility, control, and explainability.

Appendix. AI Agents: What People Think vs. What They Actually Are

AI agents have often been misunderstood as little more than chatbots or automation tools. In practice, many professionals refer to tools like Cursor, ChatGPT, or AutoGPT as "agents," but these are interface-level tools that implement only a subset of true agent capabilities. They lack autonomy, behavioral continuity, memory architecture, and decision-making systems.

The following diagram illustrates the structural gap between what most people think AI agents are, and what a fully realized agent actually consists of:

[Figure 10] Structural Gap Between What People Think and What They Are

Take ChatGPT for instance—it is a GPT-based text generation engine. While it responds to prompts with language output, it does not define goals or execute integrated actions. Cursor, which embeds GPT for coding assistance, automates within a defined scope, but lacks autonomous planning or creative goal-setting. AutoGPT, though recognized for popularizing the plan-execute loop, still operates within fixed logic cycles and limited memory. It frequently repeats actions or produces contradictory decisions in complex scenarios[4].

Such misconceptions can directly lead to design flaws and execution failures. For example, if a team begins with the idea of “adopting an agent” but simply integrates a GPT API, they will not meet core requirements such as policy enforcement, execution auditability, role separation, or accountability tracking.

To build or evaluate a real AI agent, the following components must be considered:

• Goal-oriented planning capabilities

• A standardized interface (like MCP) for connecting to external systems

• Tool selection and decision structures within execution flows

• A memory architecture capable of preserving state across interactions

• Optional agent-to-agent (A2A) collaboration support

Only when these functions are integrated into a single, cohesive system can it be properly referred to as a fully capable AI agent.

Unlike a simple chatbot, a true AI agent must go beyond user interaction and support a broad range of autonomous capabilities. Below are six essential components that define a complete and operational AI agent:

(1) Language Model–Powered Reasoning Core

At the heart of any AI agent lies a large language model (LLM) such as GPT-4. This core understands natural language, generates contextually appropriate responses, and can perform reasoning and summarization based on user instructions. However, the LLM alone cannot handle execution, tool integration, memory retention, or decision-making. It functions only as the “brain”—while the rest of the agent architecture must supply the systems that transform intent into action.

(2) Short-Term and Long-Term Memory (Including Episodic Memory)

Like a human recalling past experiences, AI agents require memory structures.

• Short-term memory: Maintains current task or dialogue context

• Long-term memory (episodic): Stores past outcomes, user feedback, and prior sessions for reuse

In practice, vector databases are used to retrieve relevant past events via similarity search, enabling consistent user experiences and incremental agent learning.

(3) Planning and Decision-Making Engine

To go beyond task execution and become autonomous, an AI agent must include a planner—a mechanism that defines what to do next based on user goals.

For example, given the instruction “analyze competitor marketing strategies,” the agent should:

1. Investigate relevant websites

2. Analyze social media trends

3. Summarize findings

4. Draft a report

This form of step-by-step decomposition and conditional branching is critical for true autonomy. While systems like AutoGPT have experimented with such loops, they still struggle with complex decisions and reasoning depth[4].

(4) Tool Integration Layer

Real-world tasks cannot be solved by GPT alone. A full agent must integrate with a range of external tools:

• Live information retrieval: Google or Bing APIs

• Computation: Calculator services or Python executors

• Data operations: SQL databases, document parsers, spreadsheet APIs

The agent must be capable of choosing and invoking these tools as needed, incorporating results into subsequent steps. This ability to act—rather than just talk—is what makes it deployable as a runtime-capable execution agent.

(5) Agent-to-Agent Collaboration (A2A)

Rather than relying on a single agent to do everything, complex workflows benefit from role-specialized agents working in coordination.

Example flow:

• Planning Agent → Creates initial draft

• Analysis Agent → Reviews and refines content

• Reporting Agent → Optimizes and delivers final output

This A2A structure improves error handling, creativity, and system resilience. Frameworks like LangGraph and CrewAI have recently emerged to support this paradigm[9][16].

(6) MCP (Model Context Protocol)

To allow AI agents to interact flexibly with new tools and systems, a standardized execution interface is essential.

MCP enables agents to:

• Automatically discover available tools and services

• Invoke APIs using a standardized format

• Reason about the feasibility of actions based on policy context

If a system supports the MCP interface, the agent can integrate with it at runtime, without requiring code changes. This provides a foundational layer for flexibility and reusability across large-scale AI ecosystems[2].

(7) Practical Example: A Marketing Research Agent

User Prompt: “Research the latest trends in AI marketing and summarize the findings in a report.”

To complete this task, the AI agent operates in the following structured sequence:

1. Intent Interpretation

Breaks down the request into actionable subgoals:

• Collect recent news
• Analyze social media trends
• Review official publications

2. Plan Generation

Constructs a task pipeline: Web search → Content aggregation → Summarization → Report writing

3. Tool Integration

Utilizes external APIs such as:

• Google Search API
• Twitter/X API

4. Memory Utilization: Retrieves results from previous research to optimize structure and content of the report

5. Output Generation: Produces a summarized report and iteratively refines it based on user feedback

6. Execution Control & Collaboration: Collaborates with a document-editing agent and dynamically connects to tools via the MCP interface

(8) Conclusion

Many people mistakenly equate tools like ChatGPT or Cursor with full-fledged AI agents. In reality, a true AI agent is an execution-capable system with a multi-layered architecture that goes far beyond surface-level interaction.

Instead of relying on surface-level behaviors, organizations must understand the underlying architecture of AI agents. A truly functional agent requires a foundation of execution control, memory management, and tool integration strategies—all working together under a consistent policy and security model. Only with this clarity can we move from “talking bots” to actionable, intelligent agents that operate securely in enterprise environments.

References

[1] IBM, “Build Trust in AI,” IBM Trustworthy AI Guide, 2023.

[2] K. Park, “Securing AI-Driven Workflows with Model Context Protocol,” QueryPie White Paper, 2025.

[3] Amazon Web Services, “Cedar Policy Language: Developer Guide,” AWS Documentation, 2024.

[4] I. Belcic, “What is AutoGPT?,” IBM Think Blog, Apr. 2024.

[5] National Institute of Standards and Technology (NIST), “SP 800-207: Zero Trust Architecture,” Final Publication, Aug. 2020.

[6] D. R. Thomas, “Software architecture as a tool for organizational alignment,” IEEE Software, vol. 29, no. 2, pp. 58–60, Mar./Apr. 2012. doi: 10.1109/MS.2012.42

[7] G. Smith, L. Zhou, and R. Patel, “Designing secure REST APIs,” in Proc. 11th IEEE Int. Conf. Web Services (ICWS), San Francisco, CA, USA, Jun. 2018, pp. 431–439. doi: 10.1109/ICWS.2018.00061

[8] T. Hinrichs and B. Bichakjian, “OPA: Policy-based control for cloud-native infrastructure,” Open Policy Agent Documentation, 2023.

[9] H. Chase and L. C. G. Rogers, “LangChain: A framework for developing applications with large language models,” arXiv preprint arXiv:2305.14322, May 2023.

[10] M. R. Anderson and S. Suri, “Orchestration of hybrid agents in cloud-native platforms,” ACM Computing Surveys, vol. 55, no. 4, pp. 1–32, 2023. doi: 10.1145/3507347

[11] J. Lee and M. Kim, “Human-in-the-loop integration for secure LLM applications,” IEEE Access, vol. 11, pp. 56102–56116, 2023. doi: 10.1109/ACCESS.2023.3278412

[12] C. Rich and A. B. Winston, “Trust boundaries in intelligent systems,” AI Magazine, vol. 33, no. 2, pp. 49–59, Summer 2022. doi: 10.1609/aimag.v33i2.2457

[13] Y. Chen and A. C. Arpaci-Dusseau, “Unifying secure proxy gateways in microservice architectures,” in Proc. IEEE Int. Conf. Cloud Engineering (IC2E), San Francisco, CA, USA, Apr. 2022, pp. 115–124. doi: 10.1109/IC2E53581.2022.00023

[14] Google Cloud, “VPC Service Controls Overview,” Google Cloud Documentation, 2023.

[15] M. Allix et al., “Cybersecurity of Large Language Models: A Survey,” in IEEE Access, vol. 11, pp. 116944–116971, 2023.

[16] L. Zeng, “Agent-as-a-Gateway pattern in distributed AI systems,” in Proc. 30th Pattern Languages of Programs Conf. (PLoP), Oct. 2023.

[17] B. Ferguson, “Designing trust boundaries in enterprise architectures,” SANS Institute Whitepaper, 2022.

[18] A. Kumar, “Zero Trust in AI service invocation,” Cybersecurity Engineering, vol. 7, no. 1, pp. 41–50, Jan. 2024.

[19] J. Lee and D. Han, “Common misconceptions in AI and access control,” in Proc. AI Security Conf., Seoul, Korea, Sept. 2023.

[20] K. Bae, Y. Hong, and S. Kwon, “Limitations of direct natural language interfaces to execution frameworks,” IEEE Internet Computing, vol. 27, no. 1, pp. 68–76, Jan./Feb. 2023. doi: 10.1109/MIC.2023.3244567

[21] SuperbCrew, “Convergence Introduces Proxy 1.0: The AI Assistant That Navigates Websites Like a Human and Gets Work Done,” SuperbCrew, Sep. 2023.

[22] OWASP Foundation, “OWASP Top 10 for Large Language Model Applications,” OWASP, 2023.

[23] L. Ding and B. Guo, “Agent architecture with execution firewalls,” IEEE Transactions on Dependable and Secure Computing, vol. 19, no. 5, pp. 1984–1995, Sept./Oct. 2022. doi: 10.1109/TDSC.2022.3149214

[24] A. Patil, H. Nam, and R. Shah, “Design anti-patterns in agent-platform integration,” International Journal of Software Engineering and Knowledge Engineering, vol. 31, no. 3, pp. 211–226, 2022. doi: 10.1142/S0218194022500113

[25] K. Park, “Google Agentspace vs. QueryPie MCP PAM: Why Security Still Matters,” QueryPie White Paper, 2025.

[26] K. Park, “AI Autonomous Access Control: When Agents Make Decisions,” QueryPie White Paper, 2025.

[27] K. Park, “Next Step: Real-Time Execution Control with MCP PAM,” QueryPie White Paper, 2025.

[28] K. Park, “Redefining PAM for the MCP Era,” QueryPie White Paper, 2025.