Governed models in every editor

Give every developer AI in their editor without scattering provider keys or losing sight of cost.

Developers want AI assistance inside their editors, but letting each one wire up a personal provider key scatters credentials across machines, leaves you with no control over which models are used, and gives you no per-developer view of what any of it costs. Rolling AI out to the whole organisation without that sprawl is the hard part.

What you can do

  • Publish a single model menu to Visual Studio Code and any OpenAI-compatible editor so that developers get AI in the editor without ever holding a provider key.
  • Require corporate SSO sign-in so that editor access is tied to a person in your identity provider, not a shared credential.
  • Filter the menu per developer so that each one sees only the company-approved models their policy entitles them to.
  • Attribute every request to the developer and their team so that editor usage is capped and charged back like any other spend.
  • Apply the same guardrails, budgets, and policies as the rest of your estate so that editor traffic is governed identically to application traffic.

How it works

EDITORSVS Code extensionOpenAI-compatible agentCorporate SSOMicrosoft Entraone Access Point URLModelprovidersIDE SurfaceDISCOVERYGET /v1/modelsentitled models onlyDISPATCHPOST /v1/chat/completionsModel Policy✕ 403 · policy deniedBACKING LLM SURFACESSurface → GPTSurface → Claudefull guardrails · budgets · policyapply on every dispatchEvery request attributed to the developer and their team

An IDE Surface has no provider of its own: it aggregates one or more LLM Surfaces into a single, governed, OpenAI-compatible model menu behind one Access Point URL. A developer’s editor signs in with corporate SSO through the surface’s central client sign-in, then calls GET /v1/models to discover only the models that developer is entitled to, and POST /v1/chat/completions to dispatch a request. Each dispatch re-runs the full governance pipeline, guardrails, budgets, quotas, policies, routing, and caching, on the backing LLM Surface under the caller’s identity, and the outcome is metered and recorded per developer and team. A per-model Policy Definition can gate an individual model in the catalogue to a subset of callers, for example one Entra group, without touching the underlying surface.

A Model Policy denial blocks the dispatch with a 403, and a policy that is set but has not compiled fails closed rather than allowing the request through.

  • Surfaces: How the IDE Surface aggregates LLM Surfaces into a governed, per-caller model menu.
  • IDE Surfaces reference: The catalogue members, central client sign-in, and per-model policy fields in detail.
  • Cost and attribution: How a member’s virtual key attributes editor usage per developer and team.
  • Security and access control: How corporate SSO identity is established before the menu is filtered.