A dev.to postmortem shows why internal AI tools demand a gateway, not a proxy

An engineering team's security near-misses with credential sprawl and prompt injection reveal the critical governance gap that simple AI proxy servers cannot fill for growing teams.

A contractor who had left three weeks earlier still had an active Jira key in their old laptop's MCP config. The team only discovered the security lapse during a routine audit. This incident, described in a post on dev.to, highlights the governance failures that occur when teams use simple proxies to connect AI agents to internal systems.

The author’s team started with a common setup. They used a basic MCP proxy to solve the protocol mismatch between local AI clients like Cursor, which speak stdio, and their remote MCP servers. The proxy's job was simple transport. It forwarded bytes, allowing developers to connect to a suite of six internal tools: GitHub, Confluence, Jira, Sentry, Datadog, and a proprietary data API. For a single developer in a dev environment, this works. The problems began as the team and the number of connected services grew.

Credential sprawl created security holes

The first failure was in access control. With the proxy model, each developer managed their own credentials for all six services. This distributed approach created significant operational overhead and security risks. When an employee departed, IT had to manually locate and revoke six separate sets of credentials across six different systems. The process was manual and prone to error, as the case of the former contractor's active Jira key demonstrates.

A gateway model centralizes this. Instead of developers holding individual API keys for each service, they authenticate once to the gateway. The gateway then manages a secure vault of service credentials and uses them to make requests on the user's behalf. This transforms de-provisioning from a multi-system scavenger hunt into a single action.

A proxy has no defense against prompt injection

The second failure was a near-miss with a malicious instruction. An agent was tasked with pulling documentation from the company's Confluence server. According to the post, a vendor had embedded a prompt injection attack inside a support ticket's formatting. Because the proxy was just a transport layer, it forwarded the raw content without inspection. The AI model began executing the injected instructions before a human supervisor intervened.

The author argues a gateway could have prevented this. By operating at the application layer, a gateway can inspect tool calls, enforce policies, and log activity with user attribution. It understands the difference between a user asking to read a document and an agent being instructed to call a different tool. It provides the audit trail necessary to investigate who did what, and when. A simple proxy provides none of these safeguards.

What we'd change

The author’s conclusion is to use a gateway. The more useful playbook, however, is defining the specific inflection point where a proxy becomes a liability. The trigger is not developer headcount. It is the moment an AI agent is granted access to a second production system or a single system containing sensitive data.

The post describes a homegrown solution, which is a common engineering response to a new problem. For most companies, building this infrastructure is a distraction. The more scalable approach is to evaluate commercial or mature open-source gateway products. The core competency to develop is not proxy engineering, but rather defining and implementing AI access policies. The question is not how to build the pipes, but what rules the traffic must follow.

Finally, the playbook should extend beyond developer tools. The author's team was entirely technical. The security and governance problems multiply when non-technical teams use AI agents connected to business systems like Salesforce or Zendesk. A gateway becomes non-negotiable infrastructure at that stage.

Landing

The distinction between an MCP proxy and a gateway is not merely technical. It is a question of corporate governance. A proxy treats AI agents as an extension of a developer's local machine, with minimal oversight. A gateway treats AI agents as first-class actors within a company's security perimeter. It subjects them to the same identity, authentication, and auditing requirements as any human employee or production service. As agents become more autonomous, that distinction is critical.

The investor read

The proxy-to-gateway narrative signals an emerging, and necessary, market for AI Agent security and governance. This pattern mirrors the evolution of API management, where simple proxies gave way to full-featured gateways like Kong and Apigee that provided security, traffic management, and analytics. The pain points described in the source, credential sprawl and lack of audit trails, are classic enterprise problems. A product that solves this for AI agents connected to corporate systems is not just a tool, but a compliance and security requirement. The key investment question is whether this becomes a new category of 'AI Gateway' platforms or a feature set absorbed by existing identity providers (like Okta) and security information and event management (SIEM) systems. The specificity of agent-based threats like prompt injection suggests a dedicated, specialized solution may have the advantage.

Pull quote: “A contractor who had left three weeks earlier still had an active Jira key in their old laptop's MCP config.”