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

> Copilot Studio connectors wire a Microsoft agent to every other system, and they live inside your Microsoft tenant. Here is how the catalog, custom connectors and connection model work, and what an owned connector layer looks like instead. Kortix is the open-source AI Operating System, with connectors declared in the repo you own.

URL: https://opensourcecopilotalternative.com/copilot-studio-connectors

## The declaration an agent needs before it may call a connector

`kortix.yaml`

```yaml
connectors:
  - slug: billing-api
    name: Billing API
    provider: openapi
    spec: https://api.example.com/openapi.json
    auth:
      type: bearer
    policies:
      - match: "get_*"
        action: always_run
      - match: "*"
        action: require_approval
```

Source: https://github.com/kortix-ai/suna/blob/dev/apps/web/content/docs/connect/connectors.mdx

One entry under connectors: in the manifest, shortened to its fields and its policy, with no credential anywhere in it.

## The two connector layers, side by side

Microsoft's cells come from its own connector and governance documentation, read in October 2026.

| | Kortix (recommended) | Microsoft Copilot Studio |
| --- | --- | --- |
| Open source | Yes | No |
| Catalog | 3,000+ apps in a click | More than 1,000 prebuilt connectors |
| Custom connectors | OpenAPI, Postman, GraphQL, MCP, raw HTTP | Custom connectors from OpenAPI or Postman |
| Where credentials live | Brokered server-side, never in the machine | In a connection in the Power Platform environment |
| Where the agent runs | Kortix Cloud, your VPC, or your on-prem network | Microsoft's cloud, inside a Power Platform environment |

## 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](https://learn.microsoft.com/en-us/microsoft-copilot-studio/advanced-connectors)). 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](https://learn.microsoft.com/en-us/connectors/custom-connectors/) wrap an API that Microsoft does not cover. The catalog runs past 1,000 connectors ([connector overview](https://learn.microsoft.com/en-us/connectors/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](https://learn.microsoft.com/en-us/microsoft-copilot-studio/mcp-add-existing-server-to-agent)).

## 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](https://learn.microsoft.com/en-us/microsoft-copilot-studio/advanced-connectors)).

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](https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-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](https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/sec-gov-phase2)). 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](https://learn.microsoft.com/en-us/microsoft-copilot-studio/publication-fundamentals-publish-channels)).

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](https://kortix.com/docs/connect/connectors) 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 above 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](/self-hosting) 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](/copilot-studio-alternatives) covers the full field, and [what a Copilot Studio agent is](/copilot-studio-agent) explains the builder itself.

## Copilot Studio connector questions

The four questions buyers ask before an agent touches a system of record.

### What are Copilot Studio connectors?

Connectors are Power Platform wrappers around an API, and Copilot Studio uses them as tools inside an agent. Microsoft ships more than 1,000 of them, and a custom connector covers an API that is not in the catalog.

### Can Copilot Studio connect to a system that is not in Microsoft's catalog?

Yes. Build a custom connector from an OpenAPI definition or a Postman collection, then add it to the agent as you would a prebuilt one. A private API needs an on-premises data gateway.

### Where are Copilot Studio connector credentials stored?

In a connection inside your Power Platform environment. Its parameters hold the authentication details and API keys, an admin can deactivate it, and it is shared through Power Apps rather than through your repository.

### Does an agent have to run inside Microsoft 365 to use its connectors?

No. Agents are created and managed in Power Platform environments and can publish to a website, a mobile app, Teams, Microsoft Copilot or Azure Bot Service channels. Microsoft 365 is one destination among several.

## Put the connector layer in the repo you own

One manifest declares the connectors, a policy decides which calls run, and the credentials stay on the server.

[Try Kortix](https://kortix.com) · [Compare the alternatives](https://opensourcecopilotalternative.com/copilot-studio-alternatives)