Cursor

Cursor is an AI-first fork of VS Code. It has a “bring your own key” mode in which its chat features call OpenAI with a key and base URL you supply — and that base URL can be the firewall. What it does not do is route all of its AI traffic that way, and the difference matters more here than on any other page in this section.

Warning

Cursor cannot be fully firewalled. Three limits, all of them Cursor’s, none of them fixable from our side:

  1. Tab completions never route through a custom key. They always use Cursor’s own models on Cursor’s own infrastructure. That traffic — which includes the surrounding contents of the file you are editing — never touches the firewall, and your guardrails never see it.
  2. Auto mode may not route through your key either. When Cursor chooses the model for you, it may serve the request from its own models rather than your configured provider.
  3. Cursor does not emit spec-compliant OpenAI tool calls. Against a standards-compliant endpoint, agent-mode tool calls may fail. Chat works.

Points 1 and 2 are compliance-relevant. If your control narrative says “every prompt our developers send is screened”, Cursor breaks that claim, and no configuration on this page fixes it.

Why put Cursor behind the firewall

It is still worth doing — you are firewalling the traffic Cursor will let you firewall, which is the chat traffic where developers paste the things you actually worry about.

  • Your provider key never sits in the editor’s config. Cursor stores your Vulnetix API key. Your OpenAI key stays in the KMS-encrypted BYOK vault and is decrypted just-in-time by the gateway, on the server side of the request.
  • Every prompt Cursor sends through your key is screened by your guardrails — including the file contents and command output it feeds back into the conversation as tool results.
  • Provider and model policy is enforced centrally. Cursor cannot silently switch to a model your organisation has not approved through your key: the decision is made at the gateway, on every request.

That last qualifier is doing real work. Read the limitations below.

Quick start

CLI

The CLI does not write Cursor’s configuration — Cursor keeps it in an internal store, not a file the CLI can safely edit. What it does is print the current instructions:

vulnetix ai-firewall install cursor

This writes nothing. It prints the steps, with your organisation UUID already substituted into the base URL, so you can copy them straight into the settings panel. Follow the Manual tab.

Store your provider key first, whichever route you take:

vulnetix ai-firewall key set openai --from-env OPENAI_KEY
Manual

  1. Open Settings → Models → API Keys.

  2. Toggle on OpenAI API Key and paste your Vulnetix API key — not an OpenAI key.

  3. Toggle on Override OpenAI Base URL and set it to:

    https://guardrails.vulnetix.com/openai/{orgUuid}/v1

    The /v1 suffix is required here — this is the OpenAI shape.

  4. Under Models, add the model IDs you want by hand — for example gpt-4o-mini. Cursor does not fetch the list from your endpoint, so a model that is not in this list cannot be selected, and a model your organisation has not approved will be refused by the gateway when you try to use it.

  5. Verify the key in Cursor’s own settings panel, then select one of your models explicitly in the chat model picker.

Note Select a specific model. Do not leave the picker on Auto. Auto mode may not route through your key at all, which means those requests skip the firewall entirely.

How it works

For the traffic it does route to you, Cursor sends POST /v1/chat/completions to https://guardrails.vulnetix.com/openai/{orgUuid}/v1 — the gateway’s chat surface. The gateway authenticates the Vulnetix API key to your organisation, applies provider and model policy, runs your guardrails over every text segment in the request, decrypts your OpenAI key from the vault, and forwards the call. Prompts and completions are never logged.

No local proxy is required. Cursor is talking to the gateway directly, using its own OpenAI provider setting.

Verify

vulnetix ai-firewall status

Cursor is reported as manual — the CLI does not manage its config and cannot read it back, so it cannot tell you whether the base URL override is on. manual does not mean wired. The absence of a bypasses_firewall warning against Cursor is not evidence that Cursor is firewalled.

The authoritative check is inside Cursor: the Verify button next to the API key in Settings → Models, which round-trips a request to the endpoint you gave it. If the override is set correctly and your key is valid, it succeeds; if the base URL is wrong, you get the gateway’s 404 rather than a generic failure.

Then send a chat message with a model you selected explicitly, and — as a deliberate test — one that a guardrail should block. A 403 rendered inside the chat pane naming the rule that fired is the only end-to-end proof that this particular request went through the firewall.

Limitations

This is the section that matters on this page.

  • Tab completions do not route through the firewall. Ever. They use Cursor’s own models, so the code around your cursor is sent to Cursor, not to your provider through the gateway. Your guardrails do not see it, your policy does not apply to it, and there is no setting that changes this.
  • Auto mode may not route through the firewall. When Cursor picks the model, it may use its own. Tell your developers to select a model explicitly.
  • Agent-mode tool calls may fail. Cursor does not emit spec-compliant OpenAI tool calls, so a standards-compliant endpoint may reject them. Chat works; agent mode may not. This is a functional limitation rather than a security one, but it is the reason Cursor agent mode is not a supported configuration.
  • The arguments the model generates for a tool call are not scanned — as everywhere else in the firewall.

If you need an editor-integrated agent whose traffic is entirely firewalled, Continue is the closer fit: it is CLI-wired, and everything it sends goes through your endpoint.

Common errors

401 — invalid Vulnetix API key

{
  "error": {
    "message": "invalid Vulnetix API key",
    "type": "authentication_error",
    "code": "invalid_api_key"
  }
}

The two-keys confusion. The OpenAI API Key field in Cursor is holding an actual OpenAI key (sk-…) instead of your Vulnetix API key. The field is named for the provider it speaks to, not for the key it should contain: the gateway authenticates you with the Vulnetix key and supplies the OpenAI key itself, from the vault. Your provider key belongs in the vault, never in the editor.

Fix:

  1. Store your OpenAI key in the vault: vulnetix ai-firewall key set openai --from-env OPENAI_KEY.
  2. In Settings → Models → API Keys, replace the value with your Vulnetix API key.
  3. Press Verify.

403 — provider_key_missing

{
  "error": {
    "message": "no OpenAI API key configured for your organisation: add one with 'vulnetix ai-firewall key set openai' or at https://www.vulnetix.com/vdb-ai-firewall#byok",
    "type": "permission_error",
    "code": "provider_key_missing"
  }
}

Your Vulnetix key is valid, but your organisation has no OpenAI key in the vault, so the gateway has nothing to forward the request with.

Fix:

  1. export OPENAI_KEY=sk-...
  2. vulnetix ai-firewall key set openai --from-env OPENAI_KEY
  3. vulnetix ai-firewall status — the openai row should now show a stored key.
  4. Retry in Cursor.

403 — model_not_allowed

{
  "error": {
    "message": "model gpt-4.5-preview is not in the organisation allowlist",
    "type": "permission_error",
    "code": "model_not_allowed"
  }
}

You added a model ID under Models that your organisation’s allowlist does not include. (A model that is explicitly denied returns model_denied instead.) Because Cursor’s model list is typed in by hand rather than fetched from the gateway, nothing stops you entering a model that policy will refuse — unlike the CLI-wired clients, where --model is validated before anything is written.

Fix:

  1. Run vulnetix ai-firewall get to see which models your policy permits.
  2. Remove the offending model ID from Cursor’s Models list and add an approved one.
  3. Select it explicitly in the chat model picker.

404 — unsupported_api

{
  "error": {
    "message": "provider anthropic does not support the OpenAI Chat Completions API (POST /v1/chat/completions). Use POST /v1/messages for anthropic: https://guardrails.vulnetix.com/anthropic/{orgUuid}",
    "type": "not_found_error",
    "code": "unsupported_api"
  }
}

Cursor speaks OpenAI chat, so its base URL must name a provider that serves the chat surface. anthropic does not — it serves messages only. The same code also appears when the /v1 suffix is missing from the base URL: the OpenAI shape requires it.

Fix:

  1. Open Settings → Models and check Override OpenAI Base URL.
  2. It must be https://guardrails.vulnetix.com/{provider}/{orgUuid}/v1, where {provider} is one that serves chat — openai, openrouter, groq, mistral, deepseek, xai, together, fireworks, alibaba, moonshot or minimax.
  3. Keep the trailing /v1.
  4. Press Verify.