Skip to main content

IDE Integration Overview

Keeptrusts supports two different IDE integration paths. They solve different problems and can be used together.

PathEndpointWhat it governs
Hosted MCPhttps://<published-hostname>/mcpKeeptrusts tools and resources invoked by the IDE agent
Model APIhttp://127.0.0.1:41002/v1 or a published model hostnameModel requests sent by a client that supports a custom API endpoint

MCP does not reroute an IDE's built-in model traffic. It adds tools such as documentation search, policy validation, history queries, and context-fabric operations. To govern prompts and model responses, the IDE or extension must also support a custom model endpoint. Prefer Chat Completions or Responses: those routes execute the documented input and output policy path.

The public Messages-shaped route authenticates, bills, routes, and proxies, but does not currently execute the Chat/Responses policy path. A native Anthropic provider target is also not adoption-ready. Do not select Messages merely because an IDE exposes that API type.

Choose the right path​

Use hosted MCP when the client supports remote streamable HTTP MCP servers. Cursor, VS Code, Windsurf, Zed, JetBrains AI Assistant, Codex, and Claude Code all have an MCP configuration path.

Use the model API when the client exposes an OpenAI-compatible base URL or a custom-endpoint provider. Current examples include Zed, Continue, JetBrains AI Assistant, VS Code custom endpoint models, and many editor plugins.

Do not point HTTP_PROXY, HTTPS_PROXY, or an IDE's generic network proxy at port 41002. The Keeptrusts model endpoint is an LLM API, not a forward HTTP proxy. A proprietary assistant that offers neither MCP nor a custom model endpoint cannot have its model traffic rerouted through this gateway.

Authentication boundaries​

  • The gateway process uses its own runtime token in KEEPTRUSTS_API_TOKEN.
  • MCP clients authenticate to a published hostname with an active Keeptrusts API token, shown in the console as an Access Key or Gateway Key.
  • Model clients send a separate Keeptrusts API token as their bearer/API key.
  • Provider credentials stay on the gateway and are referenced from policy-config.yaml; they are not model-client credentials.

Access Keys and Gateway Keys are filtered views of the shared API-token system, not separate credential stores.

What gets recorded​

Requests that actually pass through the gateway produce the normal policy, history, spend, and audit signals for their configured flow. Keeptrusts cannot record proprietary IDE traffic that still goes directly to the vendor.

Use kt events tail --follow while testing. A matching event proves that the request traversed Keeptrusts. If no event appears, treat that as a diagnostic lead rather than proof of bypass: confirm that the gateway mode is delivering events, the CLI is querying the same organization and region, the time window and filters include the request, and the active model base URL points at the gateway.

Per-client guidance​

Next steps​