Introduction

Everything in AI Governance starts with a connection, and a connection is not made in AI Governance. It is a platform object — the same one automations and pipelines use — and Discovery only borrows it. This page covers what a governance reader needs: how to make one, how to scope it, and the two mistakes that produce a connection which works and discovers nothing.

Where to find it

Connections in the platform navigation — not under AI Governance. The manager lists every connection your tenant holds, with Connections, Insights and Settings tabs, and New Connection at the top right.

Note: Discovery does not collect credentials, and this is why. Credentials live on the connection, once, and every surface that needs that platform reuses it. So a connection may already exist for the platform you want to govern — search the manager before you create a second one. Two connections to the same account are legitimate when their identities differ, and confusing when they do not.

Creating one

1. Open Connections and click New Connection — The picker opens on Select an App, showing every connector your tenant has — over a thousand — with a category rail and a search box.

2. Find your connector, and read the next section before you click it — Searching a vendor name usually returns several. Which one you pick decides whether Discovery can use the connection at all.

3. Fill in Connection Details — “Configure authentication and settings for this connection.” The fields are defined by the connector, so they differ per platform — the panel on the right carries that connector's own Instructions, and it is the authority, not this page.

4. Name it for a human — The form arrives with a generated name. Replace it — see Naming.

5. Set the Workspace — This is where an asset's workspace comes from. Leave it unset and every agent discovered through this connection has an empty Workspace column, which breaks rule-based policy targeting later.

6. Choose the authentication type and scope the identity — The single most consequential decision on the page — see Scoping.

7. Click Authorize — For OAuth connectors this hands off to the provider and returns to a confirmation step. Success reports “Successfully created a connection”; the connection appears in the manager with status Active.

8. Go back to AI Governance and add the application — The connection exists; nothing is being governed yet. See Add an Application.

Several connectors share one vendor's name

This is the first mistake, and it produces a connection that authenticates perfectly and returns nothing to Discovery.

Searching a vendor name commonly returns several connectors across different categories — a primary one, protocol-specific variants, and product-line variants that are separate products wearing the same brand. They are not interchangeable, and only some are the connector a governance platform entry expects.

Cross-check against the Supported Providers Matrix before you authenticate, not after.

Scoping the identity — the decision that matters

This is the second mistake, and it is worse than the first because it fails silently.

Discovery returns exactly what the connection's identity is permitted to list. An identity scoped to one team's workspace produces an inventory that looks complete, reports no error, and is missing most of your estate. Nothing in the product tells you the difference between "there are eleven agents" and "this credential can see eleven agents."

"An under-scoped connection does not fail. It produces a shorter list, and a shorter list looks like good news."

Three things worth settling before you authenticate:

1. Whose identity is this? — A personal account inherits one person's visibility and dies when they leave. A service identity is the right answer for anything you intend to govern continuously.

2. What is it permitted to enumerate? — Read-level access across the whole boundary you intend to govern. Governance needs to list, not to act.

3. What boundary does this connection cover? — One connection covers one account, tenant or environment. Production and sandbox are two connections, and mixing them puts test agents in your governed inventory.

The connector's Instructions panel names the specific permissions or scopes its provider needs. Where they are not yet documented for a platform, treat that as a question for your account team rather than something to arrive at by trial — an inventory that silently under-reports is the failure this whole module exists to prevent.

Naming

The form arrives with a generated name — a random two-word phrase and the app name. It is unique and it is meaningless, and it is how connection lists end up full of entries nobody can identify a year later.

Name the boundary, not the occasion. The name is what you will read in Discovery, in an incident's provenance, and in an audit response — and never put a person's or a customer's name in it.

A worked example

Illustrative only — every connector defines its own fields, and yours will differ. The Salesforce connector asks for a connection name, an optional workspace and tags, an authentication type (OAuth or a token), the instance domain, whether this is a sandbox, and the scopes to request. Its Instructions panel explains each one, including which value to use for the domain and where to obtain a client id.

The shape generalises even where the fields do not: identity, boundary, and the permissions to request. Those three are what you are really deciding on every connector.

Verify before you leave

1. The connection shows Active in the manager — Authentication succeeded.

2. Use Test Connection where the connector offers it — Reports “Test connection successful”. Cheaper than discovering a scope problem after a sweep.

3. Add the application in Discovery and run the first sweep — The real test is what comes back. A connection that authenticates and returns nothing is a scope problem, not a connection problem.

4. Compare the count against what you expected — Do this once, deliberately, while you still remember what you scoped. See Review & Triage Discovered Assets.

Disconnect and delete are different, and both reach further than AI Governance

Note: Both warn you how many assets depend on the connection, and you should read that number. A connection is shared platform infrastructure: the same one may back automations and pipelines that have nothing to do with governance. Deleting it to fix a Discovery problem can break work elsewhere in the tenant. Check the dependency count before confirming, every time.

Troubleshooting

Related

• Add an Application

• Supported Providers Matrix

• Connection Types

• Discovery Troubleshooting & FAQ