The risks of granting coding assistants direct access to internal enterprise tools came into sharp focus following a common Friday afternoon setup by a development team. Eager to query their internal notes API without switching context from Cursor, a developer copied the API base URL into their assistant settings, pasted a long-lived shared operations token into an environment variable, and added a single prompt instruction: "Only read notes. Do not change anything."
While the experiment worked initially—allowing the developer to easily check deploy freezes and on-call schedules—it broke down the following week when a second developer pointed a separate assistant at the exact same URL using the shared token. Because the notes API could not differentiate between the two users, both requests arrived bearing the identical operations credential. The access logs registered only that a generic bot had performed a search, completely obscuring which developer initiated the query.
Furthermore, the setup exposed deeper vulnerabilities. The assistant could submit search strings that the backend API interpreted as a wildcard matching all database entries because the server blindly processed whatever raw text it received. Since the notes process operated openly on the internal office network, anyone who discovered the URL could bypass the sign-in screen entirely.
This scenario highlights a growing challenge for engineering organizations as they adopt Model Context Protocol (MCP) servers and AI-powered coding assistants. When an assistant communicates via MCP, it acts as an autonomous program making arbitrary HTTP calls. Traditional internal APIs, however, are typically built for deterministic callers—such as a front-end web application navigated by human clicks or heavily reviewed backend scripts—and are rarely designed to withstand the unpredictable inputs generated by large language models.
The Risks of Direct AI Agent API Access
When a model chooses its next request dynamically from conversational text, standard access controls often fail. If an assistant is permitted to pass arbitrary strings directly into a search or database endpoint, it effectively wields a raw query language. In enterprise environments, unconstrained inputs can easily be manipulated into match-all queries or destructive commands, creating severe security blind spots.
Standard OAuth implementations within chat interfaces do little to mitigate this risk on their own. While signing into a coding assistant client may successfully authenticate who opened the chat window, that authentication rarely translates down to the underlying HTTP request searching the internal API. That downstream request still requires its own credential, and the receiving API must be able to identify the specific principal—whether an individual person or an automated service account—responsible for the action. Relying on conversational prompt instructions like "be careful" offers no real security, as servers require programmatic safeguards to reject malformed or unauthorized requests.
To address these architectural vulnerabilities, security-conscious teams are increasingly deploying a multi-layered defense pattern: wrapping internal APIs in dedicated MCP servers, enforcing strict input validation to prevent arbitrary query generation, and interposing a secure gateway between the assistant and the internal infrastructure.
Rebuilding the Architecture for Safety
Securing this workflow involves establishing a clear chain of trust where the coding assistant never talks directly to the core internal API. Instead, the assistant communicates with a dedicated gateway, which forwards requests to a restricted MCP server. This server exposes a tightly controlled, finite list of named tools rather than a generic HTTP pass-through proxy.
By avoiding generic proxy endpoints that accept raw HTTP methods, paths, and bodies, teams prevent the AI model from discovering and exploiting unreviewed administrative routes. Instead, each exposed tool corresponds to a specific, vetted function. When a search is requested, the server itself constructs the query parameters based on strict allowlists and validation rules, ensuring the model’s role is strictly limited to expressing intent rather than authoring database queries or search expressions.
Input validation layers enforce strict constraints on parameters such as maximum result limits and allowed categories, automatically rejecting any query structures that resemble wildcard operations or query language injections. Even if a prompt attempts to instruct the model to retrieve unauthorized data, the server’s programmatic checks intercept and deny the request before it reaches the backend system.
Controlling the Attack Surface at the Gateway
Placing a gateway in front of the MCP server introduces another critical security layer. Beyond handling standard session management required by streamable HTTP protocols, the gateway acts as a content filter for tool definitions.
This step is vital because authorization protocols generally only govern whether a client is permitted to communicate with a specific gateway route; they do not inspect the descriptive metadata that tools transmit to the language model. If an unauthorized or compromised tool description contains prompt injection attempts—such as instructions designed to make the model ignore previous guidelines or exfiltrate system data—the assistant would normally ingest those instructions alongside standard tool listings.
By analyzing incoming tool lists dynamically and scrubbing descriptions that exceed character limits or contain known malicious phrases, the gateway prevents adversarial descriptions from compromising the assistant’s behavior. Combined with strict principal-based auditing—where every API call is tied securely to an identifiable human user or a dedicated unattended service account rather than a shared, static token—organizations can safely harness the productivity benefits of AI assistants without sacrificing internal security boundaries.
