Secure Internal API Access for AI Agents with MCP

Integrating AI agents with internal systems offers powerful automation, but giving them direct access to your APIs can introduce significant security risks. Consider the common scenario: a developer wants their coding assistant to search an internal notes API. They copy the API URL, paste a long-lived token from a shared vault into an environment variable, and add a simple instruction: "Only read notes. Do not change anything."

On their machine, it works. But this "Friday afternoon" setup quickly breaks down. A second developer uses the same URL and token, and suddenly, the API logs show only "the bot" accessing notes, not either individual developer. The agent might send a search string like title:* OR body:*, which a real API could interpret as "match everything," even if the prompt only intended a keyword search. Worse, if the internal API is exposed on the network, anyone can bypass the assistant's login and call it directly. This common oversight highlights a critical need for structured, secure access.

The Inherent Risks of Direct AI Agent API Access

A coding assistant speaking Model Context Protocol (MCP) or similar is essentially another program making HTTP calls. Unlike the web apps and backend jobs your APIs were designed for, an AI model chooses requests based on its understanding of text. This introduces several vulnerabilities:

1. Identity and Accountability Loss: Using a single, shared token means the API logs attribute actions to "the bot" rather than a specific person or service account. This makes auditing impossible and prevents granular access control.
2. Unrestricted Querying: An AI agent might generate and send raw queries, potentially exploiting vulnerabilities or performing actions beyond its intended scope (e.g., DROP TABLE notes). Instructions like "be careful" in the prompt are insufficient; server-side validation is essential.
3. Bypassing Security Layers: If the AI agent can call the internal API directly on an internal port, it bypasses any login screens, rate limits, or audit logging mechanisms you would typically place at an API gateway.
4. Sensitive Data Exposure: Tool results could contain secrets or personal data, which the AI agent might then inadvertently carry into subsequent prompts, leading to data leakage.
5. Poor Audit Trails: Without clear identity or a central logging point, there's no reliable record of which tool ran, for whom, or with what parameters.

A Secure, Layered Approach with MCP

The Model Context Protocol (MCP) provides a standardized way for AI agents to discover and interact with defined tools. To safely grant an AI agent access, we must implement a layered solution consisting of a specialized MCP server and a teaching gateway. This architecture adheres to three core security rules:

1. Gateway-First Access: The AI assistant always calls the gateway, never the MCP server directly. The MCP server remains on an internal URL, ensuring all traffic passes through the gateway for centralized login, rate limiting, and logging.
2. Named Principal Identity: Every API call from the AI agent must run as an identified principal – either the person who asked the assistant, or a designated service account. This eliminates shared tokens and enables proper authorization and auditing.
3. Server-Side Query Construction: The AI model expresses its intent (e.g., "find notes about deploy"), but your server-side code builds and sanitizes the actual query. This prevents the model from injecting malicious or overly broad query language.

Building the Safe API Wrapper

Let's consider a simple internal notes API with list_notes, get_note, and search_notes functions. This API (notes_api.py) is intentionally basic and trusts its inputs.

Crucially, we introduce a safe_search.py module. This module contains a build_search function that rigorously validates inputs before they ever reach the underlying API. For instance, it might define QUERY_OK as a regular expression allowing only letters, numbers, spaces, and hyphens, thus rejecting title:* OR body:*. It also enforces MAX_RESULTS and validates the owner against an OWNER_ALLOWLIST. If any validation fails, it raises a SafeSearchError, preventing the unsafe query from executing.

The server.py file then wraps this enhanced logic within an MCP server using FastMCP. Each internal function is exposed as a specific MCP tool using the @mcp.tool() decorator. The tool's docstring becomes the description the AI agent reads. For the search functionality, the search_notes_tool specifically calls build_search before search_notes. If build_search raises a SafeSearchError, the tool returns an error JSON to the agent, effectively preventing an unsafe operation.

This explicit tool definition is key. There's no generic http_request tool that allows the agent to call any arbitrary API endpoint. Only the functions explicitly exposed as tools are callable by the agent.

The Essential Gateway

The gateway.py process acts as the critical front door. The AI assistant connects to the gateway (e.g., http://127.0.0.1:8090/notes/mcp), which then forwards the request to the MCP server (e.g., http://127.0.0.1:8091/mcp). While a simple teaching gateway merely forwards requests, a production-grade gateway would implement essential security features:

• Authentication & Authorization: Handling OAuth for user sign-in and attaching the user's identity (the principal) to each API call.
• Rate Limiting: Preventing abuse by slowing down callers who send too many requests.
• Audit Logging: Creating a comprehensive record of all interactions.
• Tool Description Scrubbing: Filtering tool descriptions for length or keywords (e.g., "ignore previous," "jailbreak") to prevent novel forms of prompt injection or data exfiltration via the tool definitions themselves.

This gateway ensures that even if an AI agent somehow learns the internal MCP server's address, it still can't bypass these critical controls. It's the designated entry point for all client interactions, providing a single place to enforce security policies.

By adopting this layered architecture – a carefully designed MCP server wrapping a sanitized API, protected by a robust gateway – developers can confidently provide AI agents with safe, auditable, and controlled access to internal systems.

FAQ

Q: Why can't I just tell the AI agent "only read notes, don't change anything"?

A: Relying solely on prompt instructions is insufficient because the AI model is fundamentally text-based and may not interpret or adhere to instructions as strictly as code. It can still generate malicious or unintended queries if the underlying API is too permissive. Server-side validation, as implemented in safe_search.py, provides a much stronger, enforceable guarantee that bad requests will be rejected regardless of the prompt.

Q: What's the purpose of the gateway if the MCP server already defines tools?

A: The gateway provides a crucial layer of defense and control that the MCP server itself doesn't offer. It handles external concerns like client authentication (OAuth), rate limiting, and comprehensive audit logging. It acts as a single, hardened entry point, preventing direct access to the internal MCP server and ensuring all traffic passes through the necessary security checks and monitoring.

Q: How does this approach scale beyond a simple notes API?

A: This layered architecture is highly scalable and adaptable. The notes API is merely a placeholder; you can swap it for any existing HTTP API, such as a ticket system, a Git host, or an inventory management system. The core principles remain the same: define specific tools, enforce strict input validation at the MCP server level, and funnel all requests through a robust gateway for identity, authorization, and auditing. This provides a consistent security model across various internal services.