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 hosted Radar Cloud’s identity provider or, with Radar Cloud Self-Managed, your own OIDC IdP. With Self-Managed, the IdP groups in that access token are forwarded to your clusters like a browser session’s - see Groups for AI agents over OAuth.
  • 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. 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.
diagnose remains available in read-only mode. Radar Cloud publishes a constrained version built from an explicit allowlist of its non-mutating arguments, so workload diagnosis, logs, events, and non-mutating network checks still work. in_cluster is withheld from the schema; calls that request a live probe with in_cluster: true, supply a malformed value, or include an unclassified argument are refused at call time. New diagnose arguments require a Radar Cloud update before read-only agents can use them. Read-write mode exposes the full upstream schema to normal external agents, where in_cluster may create up to five self-deleting probe pods.
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 single exception is diagnose, which has a hardcoded argument-level policy in Radar Cloud; a connected cluster cannot introduce another exception. 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