> ## Documentation Index > Fetch the complete documentation index at: https://docs.runlayer.com/llms.txt > Use this file to discover all available pages before exploring further. # Native vs. Runlayer Connectors vs. Runlayer Plugin > What the three ways of connecting AI clients to tools are, when to use each, and how to roll out from ungoverned native connectors to the governed Runlayer Plugin. There are three different ways an AI client can reach the tools your team uses. They look similar from the user's seat, but they behave very differently for security, governance, and rollout. This page explains what each one is, when to use it, and how to move from the ungoverned default to the governed golden path. Short version: **native connectors** are ungoverned and configured per-user inside the AI client. **Runlayer connectors** route the same tools through Runlayer so every call is authed, policy-checked, scanned, and audited. **Runlayer Plugin** is a single connection that exposes all of a user's Runlayer connectors at once — the golden path for company-wide rollout. ## The three options at a glance | | Native connector | Runlayer connector | Runlayer Plugin | | ----------------------------------- | ---------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | | **What it is** | A vendor MCP/integration configured directly inside the AI client (Claude, ChatGPT, Cursor, …) | A [managed MCP server](/platform-connectors) added to Runlayer via catalog, manual, or Deploy | A single, unified MCP entrypoint that exposes all of a user's active hosted Runlayer connectors and skills | | **Who sets it up** | Each end user, in their own client | Admins (users can request) | Admins roll out once; users connect one thing | | **Traffic routed through Runlayer** | No | Yes | Yes | | **Policy / PBAC** | No | Yes | Yes (delegates to each connector) | | **ToolGuard scanning** | No | Yes | Yes | | **Audit logs & analytics** | No | Yes | Yes | | **One-click / brokered auth** | No (user pastes credentials or does per-app OAuth) | Yes (incl. [OAuth Broker](/oauth-broker)) | Yes | | **Setup surface for the user** | One per tool, per client | One per connector | One connection for everything | | **Best for** | Nothing sanctioned — this is the shadow-AI default | The governed replacement for a native connector | Broad, standardized rollout across teams | ## Native connectors A **native connector** is any MCP server or integration a user wires directly into their AI client — for example, adding a vendor's MCP URL inside Claude, enabling a ChatGPT connector, or dropping a server into a local `mcp.json` for Cursor or Claude Code. Native connectors are fast for one person to set up, but they sit **outside** Runlayer: * Runlayer can't apply [policies](/platform-policies), [ToolGuard](/runlayer-toolguard) scanning, or [audit logging](/platform-audit-logs) to traffic that never passes through it. * Auth is the user's problem — often pasting an API key into a config file or running a per-app OAuth flow. * Every user configures every tool themselves, so setup drifts and duplicates across the team. Because they're ungoverned, native connectors are exactly the **shadow AI** pattern that [Runlayer Watch](/security-threats) is built to discover. Blocking them outright tends to backfire (people route around it), so the goal is to give users a sanctioned path that's *easier* than wiring things up themselves — which is what the next two options do. Native connectors inside Claude, ChatGPT, or another client can coexist with Runlayer. But Runlayer can only enforce policies, ToolGuard, and audit logs on traffic that goes through Runlayer or a supported endpoint hook. See the [connectors overview](/platform-connectors#runlayer-built-vs-vendor-native-vs-custom). ## Runlayer connectors A **Runlayer connector** is a [managed MCP server in Runlayer](/platform-connectors). It packages the MCP endpoint together with auth, configuration, permissions, and client setup instructions. Once a connector is active, every tool call flows through Runlayer, so you get: * **Identity-aware policy (PBAC)** — control exactly which users and agents can call which tools ([Policies](/platform-policies)). * **Real-time security** — [ToolGuard](/runlayer-toolguard) scans tool definitions, outputs, and intent for prompt injection, tool poisoning, and data exfiltration. * **Full audit trail and analytics** — every call is recorded ([Audit Logs](/platform-audit-logs), [Analytics](/platform-analytics)). * **One-click auth** — many vendors connect through the [OAuth Broker](/oauth-broker) with no per-tenant app registration, so users don't paste credentials into config files. There are three ways to add one — from the **catalog**, **manually**, or via **[Runlayer Deploy](/platform-deploy)** — compared in detail in the [connectors overview](/platform-connectors#comparison). A Runlayer connector is the **governed one-for-one replacement** for a native connector: same tool, but now proxied, policy-checked, scanned, and audited. ## Runlayer Plugin [Runlayer Plugin](/runlayer-plugin) is Runlayer's unified MCP entrypoint. Instead of asking users to install and manage many separate connectors, the Plugin gives them **one** connection that can discover and run every tool they already have access to in Runlayer. For each request, Runlayer builds that user's Plugin view from their active hosted connectors, accessible skills, and Runlayer platform tools — then exposes two meta-tools, `search_tools` and `execute_tool`, so the model finds the right tool instead of carrying hundreds of definitions in context. Key properties: * **No new permissions.** The Plugin only exposes capabilities the user already has; every execution still goes through the underlying connector's normal controls. * **Same security model** as direct connector use — PBAC, ToolGuard, OAuth checks, and audit logging all still apply. * **One rollout, many clients.** Admins distribute it via **Auto Sync** (CLI-managed desktop/editor clients), **Anthropic org install** (Claude), or **OpenAI org install** (ChatGPT). See [Runlayer Plugin → Admin rollout options](/runlayer-plugin#admin-rollout-options). The Plugin does **not** expose local connectors, draft/disabled connectors, or tools a user's policies block. Older organization installs may expose the Plugin's MCP server as `onelayer` rather than `runlayer-plugin`. Those installs keep working — the proxy URL and plugin identity are unchanged. ## Choosing between them Use this as the rule of thumb: * **A native connector** is what a user reaches for when there's no sanctioned option. Treat every one you find as a candidate to replace, not to keep. * **A Runlayer connector** is the right answer when you want a *specific* tool governed — you're standing up Slack, GitHub, Snowflake, or an internal MCP server and you want policy, scanning, and audit on it. * **Runlayer Plugin** is the right answer when you're rolling out to *people at scale* and don't want each user managing a list of separate connections. It's the single golden-path surface built on top of the connectors you've already approved. They aren't mutually exclusive: you approve **Runlayer connectors** for the tools you want, and then hand users **Runlayer Plugin** as the one connection that surfaces all of them. ## Rolling out: from native to the golden path A typical migration from ungoverned native connectors to the governed golden path: Use [Runlayer Watch](/security-threats) to surface the native/shadow connectors people have already wired into their clients. This tells you which tools actually matter to your teams. Add the equivalent [Runlayer connectors](/platform-connectors) from the catalog (or manually / via Deploy for internal servers). Configure auth — often one-click through the [OAuth Broker](/oauth-broker) — and apply [policies](/platform-policies). Point users at the Runlayer connector for the same tool so traffic is now proxied, scanned, and audited instead of going direct. For managed fleets you can push client config automatically — see [Auto-Sync to Clients](/auto-provisioning). Once you have several approved connectors, give users [Runlayer Plugin](/runlayer-plugin) as their single connection via **Auto Sync**, **Anthropic**, or **OpenAI** org install — instead of asking each person to add connectors one by one. Reps: the confusion usually clears up once customers see the three as a *sequence*, not competing products — discover native usage, replace it with governed Runlayer connectors, then distribute those connectors through one Plugin. ## Related docs Add and manage Runlayer connectors from the catalog, manually, or via Deploy. The unified MCP entrypoint and how to roll it out. One-click, brokered auth for connectors — no per-tenant app registration. Control which users and agents can call which tools.