Skip to Content
Welcome to the Novantra documentation.

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

StatusMeaning
proposedCreated but not yet validated. Cannot serve.
validatingValidation in progress.
validatedValidated successfully; ready to activate.
activeLive; AI systems can invoke through it.
suspendedTemporarily suspended. Invocations fail until resumed.
retiredPermanently retired. AI systems referencing it must move to another provider.
archivedArchived 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

CloudSovereign
Credential storageNovantra’s managed key layerYour install’s KMS
Provider connectionsNovantra-managed defaults + customer-addedCustomer-managed only
Network egressFrom Novantra’s cloud to the providerFrom 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

  1. AI Providers → New connection. Capture the kind, endpoint, owner.
  2. Store the credential in the install’s KMS; reference it from the connection.
  3. Run validation.
  4. On validation success, activate.

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.
Last updated on