MCP security
The practices that keep a Model Context Protocol connection safe: authenticating the client, scoping what each tool can do, isolating upstream credentials, and checking tool responses.
MCP security is the set of controls that make it safe to give an AI agent access to tools and data over the Model Context Protocol. The core risks are familiar from any integration surface: an over-privileged tool, a leaked credential, or untrusted content in a tool response that tries to steer the agent. Securing an MCP connection means authenticating the client, scoping each tool to the narrowest ability it needs, keeping secrets out of the agent, and treating tool output as data rather than instructions.
Credential isolation is the part most specific to a marketplace of paid tools. If an agent has to hold every provider's API key to call it, each connected agent becomes a place that key can leak from. The safer design keeps upstream credentials on the server and never hands them to the agent at all, so a compromised client cannot expose a provider secret.
Proxygate applies this directly. Provider keys live in the gateway and are injected server-side per request, so the agent authenticates only to Proxygate and never holds an upstream credential. Access is scoped (a call that spends requires an explicit trade scope), every paid call returns a signed receipt for an auditable trail, and an optional response-scanning mode can flag or block suspect upstream content. The same protections apply whether the agent connects over MCP, the SDK, the CLI, or REST.
References
Related concepts
MCP security: frequently asked questions
MCP security is the set of practices that keep a Model Context Protocol connection safe: authenticating the client, scoping what each tool can do, isolating upstream credentials from the agent, and treating tool responses as untrusted data.
Provider keys stay in the gateway and are injected server-side, so the agent never holds an upstream credential. Spending requires an explicit trade scope, every paid call returns a signed receipt, and an optional response-scanning mode can flag or block suspect upstream content.
If an agent must hold every provider key to call it, each connected agent becomes a place that key can leak from. Keeping upstream credentials on the server and never exposing them to the agent means a compromised client cannot leak a provider secret.