Give model access a clear route.
When each application has its own provider credentials, policies and usage records, model access becomes harder to manage. Route supported requests through PrivacyFirst to choose providers, apply content policies and set usage limits in one place.
One request. Explicit decisions.
An application sends a request using a configured access key. Policies inspect supported request content, routing selects an eligible model, and operational records make the governed call inspectable. Response policies can act on supported returned content.
Choose the model. Set the conditions.
Use configured provider APIs or private models. Routing pools support priorities, weighted distribution, retry budgets and region constraints. Provider features vary; streaming failover is limited once response delivery begins.
Set workspace and per-key request, concurrency, token and cost limits. Inspect provider attribution, latency, status and estimated spend for the traffic you route through PrivacyFirst.
Private inference can be a rule.
A workspace set to “Private models only” refuses hosted model calls, hosted fallback and external subscription execution. Private inference is one part of a private deployment; network, identity, services and update boundaries also need to be designed.
Visibility and enforcement are different jobs.
Gateway policies can monitor, warn, redact or block supported request and response content. External-tool telemetry provides another operating view; collecting that telemetry does not place those tools behind the gateway.
Supported Claude and Grok personal subscriptions use a separate vendor-direct execution path. They do not inherit every gateway control. Choose the path that fits your policy and provider terms.
Start with one application and one policy.
Bring a model-calling application, the providers it needs and a sensitive-content rule you want to test. We can trace the request path together, including the configured failure behavior and the evidence your team needs.