Where Risk Resides in AI Agent-Enterprise Interactions

MCP Helps, But it’s Not a Security Solution

This is the second part in a series detailing how LLMs impact enterprise security. Part 1 is available here, describing how structured communication protocols can deliver improved security and reliability as LLMs integrate with various systems across an enterprise.

In this blog Part 2, we dig deeper into the potential downsides and risks in using Anthropic's Model Context Protocol (MCP), and conceptually similar features like Google Gemini's Automated Function Calling (AFC).

Access Challenges

While structured protocols like MCP provide clear benefits for managing authorization requests, they don't eliminate fundamental access governance challenges when AI agents interact broadly with enterprise systems. Core risks remain, requiring proactive mitigation:

• Aggregated Permissions & Identity Complexity: AI assistants using multiple MCP-connected tools can easily accumulate excessive effective permissions ('privilege creep'). Managing these non-human identities within traditional IAM frameworks is also complex. Mitigation requires enforcing strict least privilege from the outset and employing techniques like Just-In-Time (JIT) access or the temporary, task-specific session elevation discussed earlier, alongside dedicated management of AI identities.
  
• Data Combination Risks & Audit Gaps: MCP's ease of connecting disparate data sources (e.g., CRM, HR systems, code repos) can create unforeseen privacy or compliance risks when data is combined. Additionally, fully auditing what the AI actually did requires correlating MCP request logs with detailed logs from each target system. Mitigation involves applying purpose-based data access controls where feasible and investing in centralized monitoring and auditing solutions capable of correlating activity across diverse logs.

MCP and similar protocols are necessary enablers, but are insufficient alone for security. They must be implemented alongside robust identity governance that actively applies principles like JIT access and least privilege, while providing continuous visibility and control over the actual permissions and activities of AI assistants across all connected systems.

Defining Reality: How Actions and Parameters are Exposed

While secure authorization gates access to tools, the foundation of reliable tool use lies in unambiguously defining the tools themselves: what they do, and precisely what information they need to function. This is where structured schemas become central, enabling the LLM to move beyond interpreting vague instructions and interact predictably with defined external functionality.

Frameworks following MCP principles utilize schemas, most commonly adhering to the widely adopted JSON Schema standard, to provide the LLM with a detailed, machine-readable 'manual' for each available tool. This isn't merely guidance; it's a formal specification the LLM consults to understand capabilities and structure its requests accurately.

A typical tool schema includes several key components:

• name: A unique, machine-readable identifier for the tool (e.g., Workspace_customer_data, submit_support_ticket). This is the specific identifier the LLM uses when indicating its intent to invoke this tool.
  
• description: A clear, concise natural language explanation of the tool's purpose, capabilities, and ideal use cases. This description is critical – it's the primary information the LLM leverages to determine if and when selecting this specific tool is appropriate for fulfilling a given user request.
  
• parameters (often represented within an input_schema object): This defines the inputs the tool accepts. Structured according to JSON Schema, it meticulously details each parameter, typically including:
  • name: The parameter's identifier used in the request (e.g., customerId, ticket_priority).
  • type: The expected data type, such as string, integer, boolean, array, or object.
  • description: A natural language explanation of what the parameter represents, guiding the LLM on what information is needed (e.g., "The unique identifier for the customer", "Urgency level, e.g., 'High', 'Medium', 'Low'").
  • required: An indicator (often a boolean flag or inclusion in a 'required' list) specifying whether providing this parameter is mandatory for a successful tool call.

This structured definition transforms tool interaction from potential guesswork into a more deterministic process. By programmatically parsing these schemas, the LLM can accurately perform several crucial steps:

1. Select the right tool: It can effectively choose the most relevant tool from a potentially large library by matching the user's intent to the tool description.
   
2. Identify necessary inputs: It understands precisely which pieces of information (parameters) are needed, including which are mandatory (required).
   
3. Format the request correctly: It can construct a valid request payload for the tool execution layer, ensuring parameter names, data types, and presence align with the schema's definition.

Ensuring Robustness: Handling Required Information

Defining required parameters within a tool schema is foundational, but practical application demands robust handling when that necessary information isn't immediately present in the user's request or the ongoing conversation context. Handling these gaps gracefully is crucial for creating a reliable and non-frustrating user experience.

Structured protocols, leveraging the explicit required declarations in the tool schemas, provide essential checks and balances for this exact situation. Typically, missing information is identified and addressed at two distinct layers:

1. Proactive Clarification by the LLM: In the ideal flow, the LLM analyzes the user's request against the chosen tool's schema and recognizes that one or more mandatory parameters lack values. Before generating the tool call payload, the LLM should intelligently pause the execution path and formulate a clarifying question to the user, specifically asking for the missing required details. For instance, if a create_task tool requires a due_date and none was mentioned, the LLM should respond: "I can create that task for you. What should the due date be?"
   
2. Reactive Validation by the Tool Execution Layer: If the LLM, perhaps due to ambiguity in the user's phrasing, proceeds to request the tool call without populating all required parameters, a second layer of validation occurs. The application component responsible for actually executing the tool call receives the request and performs its own strict validation against the schema. Upon detecting a missing required parameter (e.g., due_date is absent), this layer rejects the call. Critically, it sends a structured error response back to the LLM, explicitly indicating the failure reason, such as {"type": "error", "code": "MISSING_REQUIRED_PARAMETER", "parameter_name": "due_date"}. The LLM is then expected to interpret this specific error message and prompt the user for the precise piece of missing information, enabling recovery from the failed attempt.

It actively prevents malformed or incomplete requests from hitting backend APIs, minimizes silent failures where the tool might execute with default or incorrect assumptions, and ensures the system diligently works to gather all necessary inputs. The result is a higher rate of successful tool executions and a considerably smoother, more intuitive user experience.

Beyond Parameters: Structured Communication's Wider Role

The value of establishing structured communication between LLMs and external systems clearly extends beyond just defining tool inputs and managing authorization flows. A truly robust and resilient integration also hinges on standardized ways to handle the inevitable exceptions and operational errors encountered during tool execution.

Consider scenarios where a tool call fails not due to missing parameters or denied permissions covered earlier, but because the external API endpoint is temporarily unavailable, returns data in an unexpected format incompatible with expectations, or experiences its own internal server error. A well-designed protocol allows the tool execution layer to communicate these issues back to the LLM using specific, structured error types, moving beyond ambiguous, generic failure messages.

For instance, receiving a detailed error structure like {"type": "error", "code": "API_UNAVAILABLE", "message": "Service X currently unreachable"} instead of a simple 'Tool call failed' enables significantly more sophisticated and helpful responses:

• Inform the User Intelligently: The LLM can translate the specific error into clear user feedback, such as, "I couldn't reach the [Service X] API right now to complete your request. You might want to try again in a few minutes," rather than an unhelpful "Something went wrong."
  
• Enable Automated Recovery Attempts: For certain error codes indicating transient issues (like temporary network timeouts or rate limits), the system could be configured to automatically retry the request after a calculated delay, potentially resolving the issue without further user interaction.
  
• Facilitate Alternative Strategies: An advanced agent, understanding the nature of the failure via the error code (e.g., service down vs. bad input), might even be able to pivot and attempt to use an alternative tool or data source if one exists to fulfill the user's original intent.

Conclusion - Leverage Structured Interaction Protocols and Principles

Integrating Large Language Models effectively with the myriad of external tools, APIs, and data sources they need to perform meaningful work is fundamental to building the next generation of sophisticated AI applications. As we've explored, achieving this integration reliably and securely hinges on moving beyond ad-hoc prompting towards adopting structured interaction protocols and principles, such as those demonstrated by frameworks like MCP.

These structured approaches provide the necessary clarity and predictability for critical operations. By formally defining tool capabilities, required parameters, authorization mechanisms, and even error states, they deliver tangible benefits:

• Enhanced control through well-defined interaction points and validation layers.
  
• Improved security via explicit, manageable authorization checks and user consent flows.
  
• Significantly greater reliability derived from unambiguous tool definitions, precise parameter handling, and standardized error reporting that enables intelligent recovery.

As LLM-powered applications inevitably become more complex and deeply embedded within core business processes and diverse technological ecosystems, the requirement for these robust, predictable communication standards will only intensify. Understanding and implementing these principles is no longer optional; it's rapidly becoming foundational for any team committed to building powerful, secure, trustworthy, and genuinely useful AI-driven solutions that successfully bridge the gap between language understanding and effective real-world action.

If you'd like to learn more about any of these topics, schedule time with Valo and we'll connect you to the right person on our team. Our goal is to improve security, productivity and cost management for your Salesforce implementation.

About Hannu

Hannu is Co-Founder and engineering leader at Valo, driving the development of an AI-powered Salesforce platform to enhance workflow efficiency and system security. He focuses on delivering scalable, secure, and innovative solutions by mentoring teams and streamlining product development. Hannu has held leadership and engineering roles at Spotify, Infrakit, and F‑Secure, where he built robust distributed systems, optimized data pipelines, and ensured high availability and security across diverse technology environments. His expertise spans software development (Python, Java, Go), cloud computing, databases, and cybersecurity, all relevant to today’s mission to deliver impactful solutions in the Salesforce ecosystem.

• 

  Hannu Varjoranta