OpenAI
Chat, tools, streaming, and embeddings through the OpenAI-compatible gateway routes — your existing request bodies unchanged.
Integrations
Works with what you already run
Norcaster sits in the request path between your application and your models. Every entry below carries the status it has actually earned, so you can check fit before a pilot.
No per-integration fees.
- Verified
- Ships in code and has been exercised by Norcaster against the real surface.
- Compatible
- Same wire protocol as a verified entry; not individually exercised.
- Via export
- No native connector; import the exported CSV or JSON bundle.
- Roadmap
- Planned; not available today.
- Not routable
- Cannot be pointed at a gateway; listed so the scope is explicit.
Model providers
Provider adapters ship in the gateway registry. Connect credentials in Dashboard → Providers, sync models, then bind a deployment inference target.
Verified
Anthropic
Claude chat workloads; also served natively through POST /v1/messages when the deployment targets an Anthropic model.
Groq
OpenAI-compatible chat provider.
Together
OpenAI-compatible chat provider.
Amazon Bedrock
Model access through your AWS Bedrock configuration.
Voyage embeddings
Embeddings for knowledge bases and document pipelines — not a chat provider.
Azure OpenAI EU endpoints
Same OpenAI-compatible adapter with an Azure base URL and key; EU endpoints work today.
Google Gemini
Gemini Developer API on the OpenAI wire — chat, streaming and embeddings; not individually exercised against the live API. The Developer API exposes no region, so a residency tag on it stays declared, never verified.
Google Vertex AI
OpenAI wire, on self-hosted installs only: Vertex uses the Google credentials of the install itself, so no key is stored — and on the managed cloud there is no per-organisation Google identity to use yet. Not individually exercised against the live API. The region is in the endpoint, so a residency tag on Vertex is checked against it rather than taken on trust.
Hugging Face
The Inference Providers router for chat, or a dedicated Inference Endpoint, on the OpenAI wire; not individually exercised against the live API. Pin the router's downstream inference provider to fix which party processes each request.
Docs →Mistral
La Plateforme on the OpenAI wire — chat, streaming and embeddings; not individually exercised against the live API. Mistral states La Plateforme processes in the EU by default; Norcaster records that as the provider's declared residency, not as measured evidence.
Self-hosted inference
Any OpenAI-compatible endpoint gets the same input policy, output policy, and per-request trace as a cloud provider. The model stays where it is; Norcaster never sees it.
Any OpenAI-compatible endpoint
Register the endpoint as a provider; the same input policy, output policy, and per-request trace apply. Norcaster never sees the model.
Docs →NVIDIA NIM
Verified against a live NIM, September 2026; you run the NIM on your own GPUs and point Norcaster at it. Runtime identity is recorded when the NIM reports it; otherwise the record says not reported.
Docs →vLLM
OpenAI-compatible serving; registers like any OpenAI-compatible endpoint with the same policy and trace.
Docs →Ollama
OpenAI-compatible API; not individually verified.
Agent and developer surfaces
Coding assistants and agents route through the gateway with one API key per developer: input policy is enforced before the provider and credentials are blocked at the boundary. Only tool calls routed through the MCP action gateway are intercepted; direct function calls inside a process are not.
Claude Code
Routed through the gateway with the Norcaster Companion plugin or a base-URL change; credentials are blocked at the boundary before any model provider.
Codex
Codex CLI routes through the gateway from its model-provider config, with the same input-side enforcement and decision records.
VS Code extension — Norcaster Companion
Configures Claude Code and Codex to route through the gateway and keeps the key in the OS keychain; shows the governed state and blocked or redacted decisions in the editor.
CLI
pip install norcaster — deploy, run, and inspect deployments and traces from the terminal.
Docs →GitHub Action
Runs a governed bring-your-own-model workflow from CI — input policy, your model, egress policy on one trace — and validates contract config on pull requests.
OpenAI Agents / Responses API (hosted MCP tool) via the MCP action gateway
Verified 11 Sep 2026 against the production gateway: tool discovery, an allowed call, and a blocked call, each with its decision record. The escalate path was not part of that verification.
Any MCP client speaking Streamable HTTP
Connects to the MCP action gateway as a standard MCP server; not individually verified.
GitHub Copilot
Not routable: fixed endpoints cannot be pointed at a gateway.
Evidence export targets
Evidence records are hash-chained and anchored to a public transparency log; audit bundles export as PDF, CSV, or JSON and can be verified without a Norcaster login.
PDF / CSV / JSON audit bundles
Manifest-led, framework-scoped bundles with policy configuration, enforcement logs, redaction evidence, and a coverage statement — verifiable without a Norcaster login.
Docs →Offline verifier — verify_audit_bundle.py and @norcaster/verify
Checks the manifest digest, internal integrity references, and Rekor anchors without a Norcaster account or API access.
Docs →Sigstore Rekor anchoring
Trace-chain segments anchor to the public transparency log, so a third party can verify integrity without trusting Norcaster.
Docs →SIEM / GRC tools
Import the CSV/JSON bundle; no native connector today.
Identity and access
Enterprise SSO via OIDC and SAML 2.0, with SCIM 2.0 user and group provisioning, configured per organisation. Every key, session, and provider-credential event lands in the audit log.
SSO via OIDC and SAML 2.0
Enabled per organisation.
Docs →SCIM 2.0 provisioning
User and group provisioning and deprovisioning, configured per organisation.
Per-user scoped API keys
Scopes, expiry, rotation, and revocation; revoked keys keep their history.
RBAC
Organisation, team, and project roles, plus a scoped external-reviewer role for auditors and buyers.
Docs →Request-path reference
How the drop-in works
Use Norcaster as the base URL for OpenAI- or Anthropic-compatible clients. Every route below runs policy enforcement, metering, and trace capture before provider inference.
POST /v1/chat/completions
OpenAI-compatible chat, tools, and streaming. Policies and traces run in the request path.
POST /v1/messages
Anthropic Messages API proxy when the deployment targets an Anthropic provider model.
POST /v1/embeddings
OpenAI-compatible embeddings for knowledge bases and retrieval pipelines.
GET /v1/models
List models available on the bound deployment inference target.
POST /run
Deployment inference for provider-backed or self-hosted workloads, with policy enforcement before execution.
Gateway routes require X-Norcaster-Deployment-Id so the runtime knows which provider model and policies to apply.
- Point your OpenAI or Anthropic SDK base URL at the Norcaster API host.
- Add your Norcaster API key as the provider API key.
- Set X-Norcaster-Deployment-Id to the deployment that binds your provider model and policies.
- Keep your existing request bodies — policies, redaction, and traces attach in the request path.
For multi-step RAG or agent flows, compose a workflow and execute it via POST /workflows/{workflow_id}/execute instead of calling providers directly.
Internal and self-hosted workloads
Not every workload routes through a cloud API. Norcaster also runs container and bundle artifacts you build and host in your own cluster.
- Provider-backed deployments bind directly to a provider model — no container build required.
- qx-example and other demo models run immediately for onboarding and tests.
- GitHub-sourced container_image and model_bundle workloads build through the orchestrator and run via POST /run.
- GPU inference schedules on cluster nodes labeled norcaster.com/gpu=true when deployment config requests GPU.
RAG and agents
Retrieval and agent behavior run inside workflows — each step is traced, policy-checked, and linked to the same run timeline as gateway traffic.
Workflow retrieval
retrieval, rerank, and answer_with_citations nodes query knowledge bases and record citations in the trace.
Vector backends
pgvector (built into Postgres), Pinecone, Weaviate, and Qdrant — configured per vector index.
RAG API
POST /retrieval/query for semantic search; POST /rag/run for retrieve-and-answer with citations.
Agent nodes
Bounded native tool-calling loops against a provider-backed chat deployment. Tools come from function, tool_call, and mcp_input nodes.
Observability export
Norcaster records runs in its own observability store and can link enforcement events into the tracing and alerting tools you already operate.
Trace propagation
Send W3C traceparent, Datadog, or B3 headers on /run and gateway routes. Norcaster stores parent trace context on enforcement events.
Response linking
Responses include X-Norcaster-Request-Id. Configure integrations.trace_url_template to deep-link into Datadog, Honeycomb, or your own trace viewer.
OpenTelemetry export
When OTEL_ENABLED is set, enforcement spans export over OTLP HTTP with parent trace linkage attributes.
Webhooks and audit export
Per-deployment webhook_url for blocked or warned policy events. Audit bundles export signed run evidence for review outside the portal.
Portal observability
Runs, trace spans, node outputs, citations, agent steps, latency, and cost estimates in Dashboard → Observability.