> ## Documentation Index
> Fetch the complete documentation index at: https://radarhq.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Connected apps & MCP access

> Connect external AI agents to your org over OAuth, manage their grants, and clamp the whole MCP surface to read-only with an org-wide access mode.

There are two ways an AI agent reaches your clusters through Radar Cloud: a [personal access token](/cloud/personal-access-tokens) it carries as a bearer credential, or an **OAuth** grant it obtains by signing in. Connected apps covers the OAuth path and the org-wide guardrail that governs both.

## Connect an agent over OAuth

Radar Cloud's MCP endpoint is an OAuth 2.1 resource server. An MCP-aware agent that supports OAuth points at the endpoint, gets challenged, and runs a standard sign-in instead of needing a token pasted in:

* The endpoint advertises its protected-resource metadata (RFC 9728) and returns a `WWW-Authenticate` challenge on an unauthenticated `/mcp` request, so compliant clients discover where to authenticate on their own.
* Tokens are minted by Radar Cloud's identity provider (WorkOS) or, on [self-hosted](/cloud/self-hosted/index), your own OIDC IdP.
* On first sign-in the agent's user and org membership are provisioned just in time - no pre-invite step.

### Manage grants

Each agent that signs in shows up as a **connected app**. From **Settings → Tokens** you can see your connected apps and **revoke** any grant, cutting that agent off immediately.

## Org-wide MCP access mode

Independent of how an agent authenticates, every org has one switch that decides whether AI agents may *change* anything: **Settings → Tokens → MCP access mode**.

| Mode                     | Effect                                                            |
| ------------------------ | ----------------------------------------------------------------- |
| **Read-write** (default) | Agents can use the full tool surface, including mutating actions. |
| **Read-only**            | Agents can inspect, never mutate.                                 |

Read-only is enforced on both surfaces an agent could use, so it can't be routed around:

* On the **MCP endpoint**, write tools are dropped from `tools/list` and refused at `tools/call` with a tool-error the agent can surface.
* On the **cluster proxy**, the same credential can otherwise reach Radar's REST and WebSocket API directly, so mutating HTTP methods and exec / attach / port-forward sessions are refused with a `403`.

<Note>
  The mode keys on the **credential AI agents use** - PATs and OAuth grants. Browser (cookie) sessions are never gated by it, so an owner who sets read-only can still operate clusters through the UI.
</Note>

It's **fail-safe by design**: a tool with no read-only annotation, or a name no connected cluster advertises, is treated as a write and hidden. The call-time gate also keys off the specific cluster a call dispatches to, so a mixed-version fleet can't be used to slip a write past a read-only annotation on a different cluster.

## Auditing

MCP activity lands in the [audit log](/cloud/audit-log): each tool call is recorded as an audit event, alongside grant create / revoke, so you can answer which agent did what, where, and when.

## See also

* [Personal access tokens](/cloud/personal-access-tokens) - the bearer-credential path for agents and CI.
* [AI via MCP](/features/mcp) - what the MCP server exposes and why.
* [Audit log](/cloud/audit-log) - the record of agent and member activity.