Skip to main content
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 connectorRunlayer connectorRunlayer Plugin
What it isA vendor MCP/integration configured directly inside the AI client (Claude, ChatGPT, Cursor, …)A managed MCP server added to Runlayer via catalog, manual, or DeployA single, unified MCP entrypoint that exposes all of a user’s active hosted Runlayer connectors and skills
Who sets it upEach end user, in their own clientAdmins (users can request)Admins roll out once; users connect one thing
Traffic routed through RunlayerNoYesYes
Policy / PBACNoYesYes (delegates to each connector)
ToolGuard scanningNoYesYes
Audit logs & analyticsNoYesYes
One-click / brokered authNo (user pastes credentials or does per-app OAuth)Yes (incl. OAuth Broker)Yes
Setup surface for the userOne per tool, per clientOne per connectorOne connection for everything
Best forNothing sanctioned — this is the shadow-AI defaultThe governed replacement for a native connectorBroad, 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, ToolGuard scanning, or audit logging 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 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.

​
Runlayer connectors

A Runlayer connector is a managed MCP server in Runlayer. 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).
  • Real-time security — 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, Analytics).
  • One-click auth — many vendors connect through the 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 — compared in detail in the connectors overview. 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 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.
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:
1

Discover what's already running

Use Runlayer Watch to surface the native/shadow connectors people have already wired into their clients. This tells you which tools actually matter to your teams.
2

Approve Runlayer connectors for those tools

Add the equivalent Runlayer connectors from the catalog (or manually / via Deploy for internal servers). Configure auth — often one-click through the OAuth Broker — and apply policies.
3

Turn off the native connector, turn on the Runlayer one

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.
4

Distribute Runlayer Plugin for broad rollout

Once you have several approved connectors, give users 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.

Connectors

Add and manage Runlayer connectors from the catalog, manually, or via Deploy.

Runlayer Plugin

The unified MCP entrypoint and how to roll it out.

OAuth Broker

One-click, brokered auth for connectors — no per-tenant app registration.

Policies

Control which users and agents can call which tools.