[FEATURE] Read-only mode for GitOps-managed deployments

[frank-bee]

Prerequisites

• I have searched the existing issues to avoid creating a duplicate
• By submitting this issue, you agree to follow our Code of Conduct

Feature Summary

Add a read-only mode that disables all write operations (create, update, delete) in both the backend API and the UI, suitable for GitOps-managed deployments where resources are managed exclusively via Kubernetes CRDs.

Problem Statement / Motivation

When kagent is deployed in a GitOps-managed environment (FluxCD, ArgoCD, etc.), all agents, models, and MCP servers are defined declaratively as Kubernetes CRDs and reconciled by the GitOps controller. In this scenario, the UI should serve as a read-only dashboard — users can view agents, chat with them, and inspect configurations, but should not be able to create, edit, or delete resources through the UI or API.

Currently, there is no way to enforce this. The NoopAuthorizer allows all operations, and the UI always shows write controls (Create buttons, Edit/Delete overlays, etc.). This creates risk in GitOps environments where:

• UI-created resources may conflict with or be overwritten by GitOps reconciliation
• Users may accidentally modify resources that should only be changed via Git
• There's no way to provide a "view + chat only" experience

Who Is Affected

• Platform teams deploying kagent via GitOps (FluxCD, ArgoCD, Terraform)
• End users who should interact with agents but not modify infrastructure
• Security teams requiring least-privilege access patterns

Proposed Solution

Backend (Go):

• Add a ReadOnlyAuthorizer to go/internal/httpserver/auth/authz.go that implements the Authorizer interface, allowing only VerbGet operations and rejecting create/update/delete with a clear error message
• Wire it up via KAGENT_READ_ONLY=true environment variable in go/cmd/controller/main.go

Frontend (Next.js):

• Add a ReadOnlyProvider React context that reads NEXT_PUBLIC_READ_ONLY env var and exposes a useReadOnly() hook
• Conditionally hide write controls throughout the UI:
  • "Create" buttons and menus (Header, AgentList, Models page, Servers page)
  • Edit/Delete overlays on agent cards, model rows, server entries
  • Chat deletion controls
  • Agent details sidebar edit button
• Add route guards on /agents/new and /models/new (redirect to /)
• Skip the onboarding wizard when read-only (no point creating initial resources)
• Show "Resources are managed via GitOps" messaging in empty states instead of "Create your first..."

Configuration:

Environment Variable	Component	Default	Description
KAGENT_READ_ONLY	Controller	false	Enables read-only mode on the API
NEXT_PUBLIC_READ_ONLY	UI	false	Enables read-only mode in the frontend

Alternatives Considered

1. Full RBAC (issue [FEATURE] User RBAC Authorization for Kagent #1270): More comprehensive but significantly more complex. Read-only mode can serve as a lightweight first step and is compatible with the RBAC direction — it's essentially the readonly role proposed in [FEATURE] User RBAC Authorization for Kagent #1270.
2. Kubernetes RBAC only: Would protect CRDs but not the kagent HTTP API/UI.
3. Reverse proxy auth: External solution that doesn't integrate with the UI (write controls still visible, leading to confusing error messages).

Relationship to Existing Issues

• [FEATURE] User RBAC Authorization for Kagent #1270 (RBAC Authorization): Read-only mode implements the simplest form of the readonly role proposed there. When full RBAC lands, the ReadOnlyAuthorizer can be deprecated in favor of the Casbin-based system.
• [FEATURE] User concept for kagent #593 (User concept): Aligns with the direction of differentiating user capabilities.

Affected Service(s)

• Controller (Go) — authorization layer
• UI (Next.js) — component visibility

Are you willing to contribute?

• I am willing to submit a PR for this feature