Radar

In the default local mode Radar's MCP server acts with whatever identity your kubeconfig holds, often cluster-admin, and the /mcp endpoint has no authentication of its own, so any agent (or local process) that reaches it gets that full authority, including write tools. Radar does not narrow the credential or check each request against a least-privilege policy; Kubernetes RBAC on your own account is the only bound. An optional in-cluster deployment with proxy or OIDC authentication runs every write as the signed-in user through Kubernetes impersonation and filters cached reads per user, which is a real per-request authorization layer, but it is off by default and its ServiceAccount holds the cluster-wide impersonate privilege.

Radar is a tool server, so the agent host decides what to confirm; Radar's job is to label risk accurately. It does that well: read and write tools are separate, every read tool carries readOnlyHint, every write tool carries destructiveHint, and a separate /mcp-readonly endpoint drops write tools entirely. apply_resource, patch_resource and Argo sync/rollback support server-side dry-run previews, but restart, scale, rollback, cordon/drain and CronJob actions have no preview. The default endpoint that all setup instructions use exposes the write tools, and nothing on the server side requires a confirmation step.

Most tools take typed, closed schemas (additionalProperties false) with enumerated actions, and several reads clamp their limits. But the two most powerful tools are general-purpose: apply_resource accepts any multi-document YAML of any kind and patch_resource accepts any JSON/merge/strategic patch, so a misused agent can create RBAC bindings, privileged pods or anything else its identity allows. Scale has no replica ceiling and drain timeout is caller-chosen. The default endpoint ships the write group; a read-only group exists but must be chosen.

Radar never runs model code on your laptop, but apply_resource turns model-written YAML into running workloads in your cluster: the model chooses the image, command and security context, including privileged mode, host networking and host path mounts. Radar applies no pod-security or kind policy of its own, so whatever isolation exists comes from the cluster's admission controls, not from Radar. Combined with the operator's ambient credentials, a hijacked agent can run arbitrary code with node-level reach.

Radar returns cluster data (pod logs, events, annotations, CRD status, ConfigMaps) that anyone running a workload can influence. Results are structured JSON, Secret values are stripped and logs and values are scrubbed for common token patterns, but nothing marks content as untrusted for the host. A read-only endpoint exists that drops the state-change leg, yet the default endpoint gives the same session untrusted input, write tools and cluster secrets. A hijacked agent can therefore both make irreversible changes and exfiltrate data, for example by applying a pod that mounts Secrets and sends them out.

The MCP server has no memory tool, and Radar's security settings come only from user scope (~/.radar/config.json and your kubeconfig), never from a workspace. The one model-influenced persistence is the in-app investigation history: transcripts (including untrusted tool results) are kept in a 0600 SQLite file for up to 30 days and replayed into follow-up turns of the same investigation. It is per run, visible in the UI and clearable, and a write follow-up runs in a fresh session bound to user-confirmed fix text, but stored content is not validated.

The MCP server loads no plugins or remote code. Radar does, however, launch third-party agent CLIs (Claude Code, Codex, Cursor Agent, OpenCode) that it finds on your PATH, or any binary named by RADAR_AI_CLI_BIN, to run in-app investigations after a consent prompt. Nothing pins or verifies those binaries. In the default safeguarded profile for Claude and Codex the CLI gets a scrubbed environment and only Radar's tools; Cursor and OpenCode are supported only in a full-local profile that inherits your environment and auto-approves.

Radar is careful about what reaches the model: Secret values are never returned, environment variables, Helm values, CRD fields and logs are scrubbed for common token patterns, and usage statistics are opt-in counts only. Radar holds no API keys of its own by default; it uses your kubeconfig without exposing it. Two gaps remain: every MCP call's full arguments are printed to the terminal log, so a Secret applied through apply_resource is logged in plaintext, and cluster Secrets remain reachable indirectly (a model can apply a pod that prints them, defeated only by pattern-based log redaction).

Every MCP tool is wrapped by one logging function that prints the tool name, the full arguments, success or error, and duration, plus a structured logfmt line. That gives a usable per-call trace, but it goes only to the process's standard output, records no caller identity, and is lost when the terminal closes. Kubernetes' own audit log and Radar's field manager on writes are the durable record, and those live outside Radar.

Several tools enforce server-side caps (events up to 100, changes up to 50, top up to 100, multi-pod logs 32 KB, bounded diagnose bundles, rightsizing scans up to 3 minutes). Others are open-ended: list_resources has no limit, single-pod log tail length and drain timeout are whatever the caller asks, and there is no rate or concurrency limit on tool calls, including writes. Radar's own investigation runner adds a 15-minute turn timeout, 15 model turns and 3 concurrent runs, but that does not bound an external agent using /mcp.