Copilot Studio connectors, and the open source layer you can own

What a Copilot Studio connector actually is

Microsoft builds connectors in Power Platform, and its own documentation describes them as proxies or "wrappers" around APIs (use connectors in agents). Four products share that catalog: Copilot Studio, Power Automate, Power Apps and Azure Logic Apps. A connector built for one is available in the others. Inside an agent a connector arrives as a tool: you add it on the agent's Tools page, or drop it into a topic as a node.

There are three kinds. Standard connectors such as SharePoint ship with every Copilot Studio plan. Premium connectors need a plan that includes them. Custom connectors wrap an API that Microsoft does not cover. The catalog runs past 1,000 connectors (connector overview), and a connector arrives in an agent as a tool.

MCP has its own path in. You add a server through the MCP onboarding wizard with a URL and one of three auth choices: none, API key, or OAuth 2.0. Copilot Studio supports the Streamable transport and dropped SSE after August 2025 (MCP servers in Copilot Studio).

A connection is the credential, and it lives in the environment

Adding a tool is the easy half. The agent also needs a connection, and the connection is where authentication happens. By default Copilot Studio asks the person using the tool to sign in with their own account. The alternative is maker-provided credentials, which needs an authenticated channel (use connectors in agents).

Connections have a lifecycle. The Connection settings page lists each one with a status: connected, not connected, deactivated, expired or stale. A deactivated connection, Microsoft notes, was possibly turned off by an admin. Behind it, the connection parameters hold "authentication details, API keys, or other required information" (create and manage connections).

Then there is the environment. Microsoft's governance guidance is direct: agents are always created and managed inside Power Platform environments, and the environment "determines where your agent's data lives, who can build or edit it, which connectors and integrations are allowed" (zoned governance). In Copilot Studio the connector layer is a tenant boundary, and every grant, credential and audit record sits behind it.

Where the agent is published decides what the connector reaches

A connector only matters on a surface where the agent runs. Copilot Studio publishes to Teams and Microsoft Copilot, SharePoint, a demo site, a custom website, a mobile app, and the Azure Bot Service channels. Publishing applies to every connected channel at once (publish and deploy).

Authentication follows the channel. Agents default to "Authenticate with Microsoft", which uses Entra ID for Teams, Power Apps and Microsoft Copilot with no setup. Choose "No authentication" and the agent cannot use tools that need a person's credentials. For a team whose work lives in Teams, that is the shortest route from a connector to a working agent.

What a project declares before an agent may call a connector

Kortix treats the connector layer as configuration in the repo. Each connector is an entry under connectors: in kortix.yaml, with a slug, a name, a provider, and whatever that provider needs: an app slug, a server URL, an OpenAPI spec, a Postman collection, a GraphQL endpoint or a base URL for raw HTTP. Policies sit in the same entry, so the rules travel with the declaration.

The manifest never holds a credential, as Kortix documents, so a diff of kortix.yaml shows every system an agent may touch. A reviewer can read the whole change without a secret in it.

Granting is a separate decision. An agent reaches only the connectors its agents.<name>.connectors list names, and a call outside that list fails with connector_not_assigned. A policy decides whether a matching call runs, waits for approval, or is blocked. With both in place, a project gets "3,000+ apps in a click, plus MCP, OpenAPI, Postman, GraphQL and raw HTTP."

Which connector layer fits your team?

Start with where the systems live. If the estate is Microsoft, the agents run in Teams, and governance already flows through Entra ID, Copilot Studio connectors are the shortest route. The catalog covers Microsoft services first, connections inherit the environment's controls, and nothing new has to be hosted.

Look harder when the systems that matter sit outside that estate: the CRM, the ticketing system, the repo, the billing API. Reach is still possible through custom connectors, but each one is a Power Platform artifact, its connection belongs to the environment, and its API definition lives in the Power Apps portal rather than in your repository.

The third case is a team that wants the definitions and the credentials outside any vendor's tenancy. That is what the Kortix layer is for, and the comparison table on this page sets the two side by side.

An owned layer keeps the declaration and the credential apart

A Kortix connector is declared once and used everywhere: a session, a trigger, a webhook. MCP and OpenAPI sit next to the managed catalog as first-class providers, and so do Postman collections, GraphQL and raw HTTP. Connector credentials are brokered server-side and never enter the machine, so a session can call a tool without ever holding the token for it.

Day two is about who may call what. Per-resource permissions for people and agents. Roles, groups, and an audit trail. The declaration and the grant are both files, so a change to either is a change request a person reads before it lands.

Ownership is the last piece. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free, and the self-hosting page covers the install. A connector layer that runs on your network, reads its declarations from your repo and keeps credentials on the server is portable. It follows the repo to the next vendor, and the next model.

If the decision is wider than connectors, the Copilot Studio alternatives page covers the full field, and what a Copilot Studio agent is explains the builder itself.