Skip to main content
There are two ways an AI agent reaches your clusters through Radar Cloud: a personal access token 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, 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.
ModeEffect
Read-write (default)Agents can use the full tool surface, including mutating actions.
Read-onlyAgents 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.
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.
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: 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