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. AI systems registered in AI Systems point at provider connections for the actual model invocations.
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.
- 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 are the upstream plumbing.
What lives in a connection
A single record type:
Provider connection carries:
- A stable key and a title.
- The provider kind (
openai-compatible,anthropic-compatible,azure-openai,vertex-ai,internal-gateway, etc.; free text). - The endpoint (URL or identifier).
- 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.
Status lifecycle
| Status | Meaning |
|---|---|
proposed | Created but not yet validated. Cannot serve. |
validating | Validation in progress. |
validated | Validated successfully; ready to activate. |
active | Live; AI systems can invoke through it. |
suspended | Temporarily suspended. Invocations fail until resumed. |
retired | Permanently retired. AI systems referencing it must move to another provider. |
archived | Archived for historical reference. |
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).
- Validation history.
- Activation, suspension, rotation, retirement events.
- AI systems currently referencing this connection.
- Activity history.
Every change is captured in the workspace Audit Log.
Cloud and Sovereign
| Cloud | Sovereign | |
|---|---|---|
| Credential storage | Novantra’s managed key layer | Your install’s KMS |
| Provider connections | Novantra-managed defaults + customer-added | Customer-managed only |
| Network egress | From Novantra’s cloud to the provider | From your install to the provider |
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.
Common workflows
Adding a connection
- AI Providers → New connection. Capture the kind, endpoint, owner.
- Store the credential in the install’s KMS; reference it from the connection.
- Run validation.
- On validation success, activate.
Rotating credentials
- Provision the new credential at the upstream provider.
- Update the credential reference on the connection.
- Verify validation still succeeds.
- Decommission the old credential at the upstream provider after grace.
Suspending and resuming
- From the connection, transition to
suspendedwith rationale. - Invocations fail until resumed.
- When the cause is resolved, transition back to
active.
Retiring
- Move any AI systems referencing the connection to a replacement.
- Transition the connection to
retired. - 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.