AI Providers

An AI provider connection is your workspace’s link to an upstream AI provider — a model vendor, a hosted-AI service, an internal AI gateway. Each connection has its own lifecycle: validated, activated, rotated, suspended, retired. Credentials never live in plaintext in the workspace; they live in your install’s key management layer and are referenced by the connection.

Provider connections are the upstream side of AI Governance. Approved model records sit under those connections and define which models can be used for which surfaces, capabilities, data classes, and residency posture. AI profiles bind to an approved model before a workflow can run.

Provider execution uses reviewed adapter types. Current executable adapters support OpenAI-compatible endpoints, local/internal OpenAI-compatible endpoints, and Gemini. Other native provider adapters may appear as governance or planning descriptors before they are executable. A model family such as Jais is approved as model metadata under a supported endpoint; it is not itself a provider driver.

When you would reach for this

You set up provider connections when:

• A new AI system needs an upstream provider before it can serve invocations.
• A workflow needs a newly approved model, capability, or local/internal endpoint.
• Credentials need rotation per your organization’s policy.
• A provider needs to be suspended (provider incident, contract dispute, security investigation) without retiring it permanently.
• A provider needs to be retired (replaced by another provider, service discontinued, contract ended).
• A new region or environment needs its own connection (production vs sandbox, primary vs failover).

You don’t reach for this for using the provider through an AI system (that’s the AI Systems registration) or for authorizing members to invoke (that’s Use Authorizations). Provider connections and approved models are the upstream runtime control layer.

What lives in a connection

Provider connection carries:

• A stable key and a title.
• The provider kind or driver, such as an OpenAI-compatible endpoint, a hosted provider, or an internal gateway.
• The endpoint or routing identifier. Local/internal OpenAI-compatible endpoints can be used when your install policy approves them.
• The credential reference (pointer into your key management layer; never the credential itself).
• A status walking through proposed, validating, validated, active, suspended, retired, archived.
• An owner (a responsibility assignment).
• A connection snapshot capturing model availability, rate limits, region, contractual basis.

Approved model carries:

• The provider connection it belongs to.
• The model name or deployment name used by the provider.
• Lifecycle status, such as approved, suspended, or retired.
• Capabilities such as structured JSON, text generation, or embeddings.
• Allowed AI surfaces, such as Document Intelligence, context embedding, context retrieval, or broader governance assistance.
• Data classification, residency, and transfer posture where your policy requires it.

Provider, model, and profile policy snapshots can also carry AI data-boundary settings such as provider posture, permissivity, rule-pack references, classifier references, route targets, use-case and oversight references, reversible-tokenization posture, and override posture. These settings govern whether a handoff is allowed, warned, redacted, tokenized, routed to an approved internal model, or blocked before content reaches the model and before model output becomes reviewable evidence.

A provider can be active while a specific model remains unavailable. A model can also be blocked for a workflow if it lacks the required capability or is not approved for the data classification being processed.

Credential references can point at the secret manager approved for your deployment. Common examples are Azure Key Vault secrets, AWS Secrets Manager secrets, a HashiCorp Vault KV secret in a sovereign or on-premises install, or an encrypted local/static credential mode approved by your operator. Use placeholder-style references in documentation and tickets, for example azure-keyvault://example-vault/ai-provider-key, aws-secretsmanager://me-central-1/example/ai-provider-key, or hashicorp-vault://kv/example/ai-provider-key?field=apiKey; never paste the credential value itself.

Status lifecycle

A worked example: a reinsurer manages provider connections across regions and roles

A reinsurer operates globally, with regulatory commitments around data residency, supplier risk, and operational resilience. They maintain provider connections deliberately: a primary hosted AI provider in the EU for European data, a separate connection for the Americas, an internal AI gateway for sensitive workloads, plus sandbox connections for development. The head of AI governance, Mahmoud, sets up Providers like this.

Step 1: register each connection.

• provider-a-eu — kind hosted, EU region, primary for European AI systems.
• provider-a-americas — kind hosted, Americas region.
• provider-b-internal-gateway — kind internal-gateway, all-region routing for sensitive workloads through the reinsurer’s own model serving infrastructure.
• provider-a-eu-sandbox — kind hosted, EU region, sandbox for development.

Each registration captures the endpoint and a credential reference; the credential itself sits in the install’s KMS, referenced by the connection.

Step 2: validate. Each connection runs through validation: a probe call to verify the credential resolves, the endpoint is reachable, the expected models are available, response times are within expectations. The validation result is captured on the connection.

Step 3: activate. Validated connections are activated and become available to the AI systems that reference them.

Step 4: rotate. Quarterly, per security policy, Mahmoud rotates credentials on each production connection. Rotation:

• A new credential is provisioned in the upstream provider.
• The credential reference on the connection is updated to point at the new credential.
• The old credential is decommissioned at the upstream provider after a grace window.

The connection’s audit trail records each rotation.

Step 5: suspend. When the upstream provider notifies of a security advisory affecting one connection, Mahmoud suspends it. AI systems that reference it fail with a clear error; invocations queue if applicable. When resolved, the connection is reactivated.

Step 6: retire. When a contract is ended (provider B is being replaced by provider C across the entire reinsurer), the connection moves to retired. AI systems referencing it must be reconfigured to point at the replacement, then the retired connection is archived.

After a year:

• The provider connection register is the audit-grade inventory of upstream AI relationships.
• Credentials are rotated on schedule with documented records.
• Suspensions during provider incidents have audit trails.
• A regulator or board can be shown which providers serve which AI systems, with their lifecycle records.

What you’ll see in the product

AI Providers lives under Governance → AI Governance → AI Providers in the workspace.

The Connections list shows every connection with its kind, region (from snapshot), status, last validation time, owner.

Inside a connection, you see:

• The full record and snapshot.
• The credential reference (resolved name; the value itself is not displayed).
• The approved models associated with the connection and their allowed uses.
• Validation history.
• Activation, suspension, rotation, retirement events.
• AI systems and profiles currently referencing this connection or one of its models.
• Activity history.

Every change is captured in the workspace Audit Log.

Cloud and Sovereign

In both deployments, the credential value itself is never displayed or returned from the workspace. The connection holds the reference; the resolution happens at invocation time inside the encryption boundary. For customer-hosted or open-source models, use an approved local/internal OpenAI-compatible endpoint and bind profiles to approved model records for that endpoint.

Data-boundary evidence is sanitized. It records policy references, decision IDs, outcomes, categories, counts, provider and model references, incident-candidate posture, and risk flags. It does not expose raw prompts, source text, provider payloads, vectors, embeddings, storage keys, credentials, or token maps.

Common workflows

Adding a connection

1. AI Providers → Add provider. Choose the provider type or internal gateway pattern, then capture the connection name and endpoint.
2. Store the credential in the deployment-approved secret manager, such as Azure Key Vault, AWS Secrets Manager, HashiCorp Vault KV for sovereign/on-premises installs, or another operator-approved bridge; reference it from the connection.
3. Select the models this connection is allowed to expose. For known provider types, Novantra suggests common model templates. For private, newer, Azure deployment, local, Jais, or internally served models, add the model name your endpoint expects.
4. Choose the default model from the approved list and review the model capabilities and allowed data posture.
5. Save the connection with an audit reason, then run validation.
6. On validation success, activate the provider and bind AI profiles to one of its approved models.

Rotating credentials

1. Provision the new credential at the upstream provider.
2. Update the credential reference on the connection.
3. Verify validation still succeeds.
4. Decommission the old credential at the upstream provider after grace.

Suspending and resuming

1. From the connection, transition to suspended with rationale.
2. Invocations fail until resumed.
3. When the cause is resolved, transition back to active.

Retiring

1. Move any AI systems referencing the connection to a replacement.
2. Transition the connection to retired.
3. Archive once no records reference it.

Related

• AI Systems - systems reference provider connections.
• Self Managed Secret Keys - where credentials actually live.
• Party Engagements - upstream providers are typically party engagements.
• Monitoring - provider availability is monitored.
• Incidents - provider outages become incidents.