[FEATURE] feat: Add read-only mode / role-based UI access control

[vinodkumar-wagh]

📋 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 read-only mode / role-based UI access control

❓ Problem Statement / Motivation

Feature Request

Summary

Add support for a read-only (view-only) UI mode and/or role-based access control,
so operators can expose the kagent UI to developers without granting them the ability
to create, edit, or delete agents, models, and tool servers.

Motivation

Currently, the kagent UI is fully writable — any user with access can edit or delete
agents, model configs, and tool servers. In team environments, there is often a need
to separate:

• Operators/Admins — who manage and configure agents
• Developers/End-users — who only interact with (chat with) agents

Without this separation, granting UI access to a broader audience risks accidental
or unauthorized modification of production agent configurations.

Proposed Solution

Option A: Read-Only Mode via Environment Variable (minimal, low effort)

Introduce a NEXT_PUBLIC_READONLY_MODE=true environment variable that hides/disables
all mutation controls in the UI:

• Hides the Edit and Delete options on AgentCard (dropdown menu)
• Hides the Edit button in AgentDetailsSidebar
• Hides the New Agent, New Model, Add Server buttons/pages
• Can be set via the Helm chart's ui.env block:

ui:
  env:
    NEXT_PUBLIC_READONLY_MODE: "true"

💡 Proposed Solution

Introduce a NEXT_PUBLIC_READONLY_MODE environment variable for the Next.js UI.
When set to true, all mutation controls are hidden or disabled:

• Remove the Edit and Delete options from the agent card dropdown menu (AgentCard.tsx)
• Hide the Edit button in the agent details sidebar (AgentDetailsSidebar.tsx)
• Hide or redirect the New Agent, New Model, and Add Server entry points

This requires no backend changes. It can be toggled via the Helm chart's existing
ui.env block:

ui:
  env:
    NEXT_PUBLIC_READONLY_MODE: "true"

This allows teams to deploy two UI instances from the same image — one full-access
for admins/operators, one read-only for developers who only need to chat with agents.
It's a low-effort, non-breaking change that lays groundwork for more formal
role-based access control in the future.

🔄 Alternatives Considered

Alternative 1: Two UI Deployments (admin + viewer)
Deploy two instances of the UI with different env configs — one full-access for
admins, one read-only for developers. No code changes beyond Option A are needed
to support this pattern once Option A is implemented.

Alternative 2: Role-Based Access (longer term)
Introduce an authentication layer with admin/viewer roles. This is a larger effort
and likely out of scope for Alpha, but Option A lays the groundwork.

🎯 Affected Service(s)

UI Service

📚 Additional Context

No response

🙋 Are you willing to contribute?

• I am willing to submit a PR for this feature