Connector policy, credentials and activity
For Owners, Operators and anyone with the ConnectorGovernance Role, who want connectors to follow rules the whole organisation sets: which MCP servers and sign-in methods are allowed, which credential reaches which deployments, who called which tool, and whether the servers are answering. Connectors are always created in a Studio and shared through a Library; Organisations does not create them, it controls how they are shared, used and watched.
Before you start: Organisations 1.1.3 or later, with the Studios you govern on Studio 2.1.6 or later. A Studio on an earlier release shows Needs Studio 2.1.6 or later wherever a feature reaches it, and is skipped without a change. After you upgrade Organisations, upgrade the Studios: that upgrade also sets up each Studio's sign-in address (Upgrading Organisations). Until then a person pressing Connect on a Studio sees "Sign-in is not set up on this Studio yet. Ask your administrator to update the Studio."
Who can do what
| Task | Needs |
|---|---|
| Read and change the policy; share, rotate and withdraw a credential; read connector tool calls | The Owner or Operator tier, or the ConnectorGovernance Role (organisation-wide). Sharing a credential also needs rights to manage the Library. |
| Read the policy's state per deployment and connection health | Anyone who can view the Fleet |
Share a connector to a group
- In a Studio, create the connector and share it into a Connector Library (Libraries and sharing).
- In Organisations, make the Library's members the Entra users and groups who may download it (Libraries). A person who is not a member does not see the item.
- Members download it into their Studio. A copy carries the connector's setup only. Each member then connects their own account, or you share the connector's credential (below).
Organisation-managed credentials
A connector that uses a service credential (a key, token or client secret), or a personal sign-in connector that needs the sign-in app's client secret, can have that credential managed centrally. You or the connector's owner enter it in the source Studio; Organisations relays it to the deployments and groups you choose, and keeps only a record of what was relayed, not a copy of the secret. A connector that needs no credential, or signs in with AWS IAM, cannot have one.
- Open Libraries, open the Connector Library and the item, and find Organisation-managed credential.
- Click Share this connector's credential. Choose Deployments, optionally Only for these groups (optional) (Entra groups), Expires on (optional) and Label, and save. "Studio users enter and change this credential in source deployment. Changes reach every deployment listed here within a few minutes."
- Read the status per deployment:
| Status | Meaning |
|---|---|
| Relayed, version n, time | Every matching copy in that deployment holds the credential |
| Waiting | The next relay has not reached it yet |
| No copy yet | No one in that deployment (or in the chosen groups) has downloaded the connector |
| Needs Studio 2.1.6 or later | That deployment cannot receive it until it is updated; nothing was written |
| Failed: reason | The relay did not complete; Relay now retries |
| Withdrawn | The credential was withdrawn |
In a governed Studio the connector is shared by everyone on the deployment, so the group decides only whose download receives the credential.
Rotate. Change the credential in the source Studio (Add credential, or Update). Organisations notices the change and relays the new version to every copy within a few minutes; agents use it on their next call. In every receiving Studio the connector shows Managed by your organisation, "Updated time" and its Expires on date, and its Add credential is disabled: "Your organisation manages this credential." The source Studio's page reads "Your organisation shares this credential with n deployments. Changing it here updates all of them."
Withdraw. Click Withdraw credential and confirm: "Withdraw this credential from every deployment? Agents there stop using it at once." The relayed credential is removed from every copy, which becomes Needs a credential with "Your organisation withdrew this connector's credential. Add your own credential to keep using it." and the person adds their own. The source Studio's own credential is not touched, and a withdrawn credential is not restored: share it again to start a new one.
For a connector where each person signs in, only the sign-in app's client secret is ever relayed. "Each person connects their own account. No one's sign-in is shared." is shown on such items, and Organisations never reads a personal credential (Each person signs in to an MCP connector).
Connector policy
Open Connector policy (in the dock's Libraries group). "Applies to MCP connectors in every Studio of this organisation." Without a saved policy everything is allowed.
| Setting | Choices |
|---|---|
| Approved MCP servers | Allow any MCP server, or Only these servers with a list of hosts. Use *.example.com to allow every subdomain (it does not match example.com itself); an exact host or an IP address matches only itself. Only these servers with an empty list allows none. |
| Allowed sign-in methods | No authentication, Shared key, Each person's own key, Client credentials, Each person signs in, Microsoft, on behalf of each person, AWS IAM |
| Organisation-managed credentials | Allowed or Not allowed. Not allowed also stops Studios using credentials copied by Library downloads from before Studio 2.1.5, and suspends every credential you have shared. |
| Tool arguments in the audit | Record a fingerprint or Do not record. Arguments themselves are never recorded either way. |
Click Save. Below the form, a table lists each deployment, its Studio version and its state: Enforced, Waiting or Needs Studio 2.1.6 or later.
What a Studio does with the policy:
- A person saving or testing a connector that breaks it is refused with the reason: "Blocked by your organisation's policy: host is not an approved MCP server." or "Blocked by your organisation's policy: this sign-in method is not allowed for MCP connectors."
- An existing connector that breaks it shows "Blocked by your organisation's policy" and agents cannot call it. Studio shows a banner to its owner (Banners you may see). Credentials copied by a Library download are refused with "Blocked by your organisation's policy: credentials copied from another Studio cannot be used. Add your own credential." when organisation-managed credentials are not allowed.
- Policy applies to MCP connectors only. SQL, Snowflake, REST and AWS connectors are not affected.
- Every save is recorded in Audit.
Read connector activity
Open Identity & Access Management → Audit and choose the Connector tool calls tab. One row per call an agent made through an MCP connector:
| Column | Shows |
|---|---|
| Time, Person, Deployment, Connector, Tool | When, whose account the call ran as, and what was called |
| Outcome | Completed, Tool error, Refused, Failed, Not approved, Asked for approval or Asked to connect |
| Approval | Who allowed a call that asks before running |
Filter by deployment, connector, person and date range. "Kept for n days." (365 days in Organisations). The tab does not count toward usage and does not fill the main audit list, which is unchanged (Audit). A call made with an API key is recorded against the key, not a person. Organisations collects the rows from each Studio on its regular sync.
Each row holds identifiers and a fingerprint of the arguments (or nothing, under Do not record). It never holds the arguments, a result, a token or a credential.
Watch connection health
The deployment's Overview has a Connectors card (Deployment detail): its sign-in address for registering with providers, and each MCP connector as Working or Not responding since time. Studio checks each connector about every 15 minutes, so a change shows within that time, and a connector that needs a credential is not checked.
Notes
- A Studio applies a policy change on its next sync, within a few minutes; the deployments table reads Waiting until then.
- A Studio below 2.1.6 refuses a Library download of a connector where each person signs in, before anything is written, with "This connector uses a sign-in method that needs a newer Studio release on the receiving deployment. Update that deployment, then download it again."
- The sign-in redirect address is per Studio and the same for every connector in it. Register it in each OAuth and Microsoft Entra app the connectors use.