Enhances the merged security doc (#8203) with four mermaid diagrams
that make the architecture and posture choices visible at a glance:

1. **Component diagram** — replaces the ASCII-art architecture block
   with a richer mermaid flowchart that groups components by trust
   boundary (user machine / console deployment / managed clusters /
   AI providers), uses solid vs dashed arrows to distinguish
   mandatory vs optional flows, and color-codes the boundaries.

2. **Auth + transport defense-in-depth** — shows the four layers
   that gate traffic into kc-agent (bind check on 127.0.0.1, CORS
   allow-list, DNS-rebinding guard, optional KC_AGENT_TOKEN) so
   readers can see why loopback alone isn't the whole story and
   when they should set the token.

3. **Posture comparison** — stacks the three network postures
   (fully online / restricted egress / fully air-gapped) side by
   side with red dotted arrows marking the flows explicitly
   blocked at egress in each posture.

4. **Local-LLM provider-slot routing** — shows how setting
   GROQ_BASE_URL (or OPENROUTER_BASE_URL / OPEN_WEBUI_URL)
   redirects the provider slot to Ollama, vLLM, LM Studio, or
   a corporate gateway without touching the console code.

Also adds a short "Local LLM as a security posture" subsection
framing the override as the correct choice for air-gapped and
high-sensitivity environments — not a feature gap. This is
deliberately scoped to the security doc; broader local-LLM
support work lives elsewhere.

No runtime behavior changes. Documentation only.

Signed-off-by: Andrew Anderson <[email protected]>

…detail

Makes the security picture visible in-context at the two moments
users care about — installing the Console itself and installing
a CNCF project via a guided mission. Both surfaces link to the
SECURITY-MODEL.md doc merged in #8203.

Setup install modal (SetupInstructionsDialog.tsx):
- New expandable "Security posture" section next to the Dev
  Guide / K8s Deploy / OAuth sections
- Four subsections covering kc-agent posture, AI key handling,
  what leaves your machine, and the air-gapped / local-LLM
  option (framed as a security posture, not a feature gap —
  deliberately scoped to NOT conflate with the separate broader
  local-LLM support work)
- "Read the full security model" link to docs/security/SECURITY-MODEL.md

Mission Detail view (MissionDetailView.tsx):
- New 5th tab: install / uninstall / upgrade / troubleshooting /
  **security**
- Renders mission.security steps via the existing StepCard
  component
- When mission.security is populated, adds a footer link to the
  overall SECURITY-MODEL.md so users always have a path to the
  full doc
- When mission.security is empty, shows a helpful fallback with
  the global doc link and an "Suggest security notes" button
  (reuses the existing onImprove flow)

Schema (lib/missions/types.ts):
- Adds optional `security?: MissionStep[]` to the MissionExport
  interface. Backwards-compatible.

Locale (locales/en/common.json):
- Adds `missions.detail.tabs.security` and
  `missions.detail.tabs.securityEmpty` strings

Paired with kubestellar/console-kb#2027 which introduces the
schema-side `mission.security` array and populates the first
mission (install-kubevirt).

Signed-off-by: Andrew Anderson <[email protected]>

Enhances the merged security doc (#8203) with four mermaid diagrams
that make the architecture and posture choices visible at a glance:

1. **Component diagram** — replaces the ASCII-art architecture block
   with a richer mermaid flowchart that groups components by trust
   boundary (user machine / console deployment / managed clusters /
   AI providers), uses solid vs dashed arrows to distinguish
   mandatory vs optional flows, and color-codes the boundaries.

2. **Auth + transport defense-in-depth** — shows the four layers
   that gate traffic into kc-agent (bind check on 127.0.0.1, CORS
   allow-list, DNS-rebinding guard, optional KC_AGENT_TOKEN) so
   readers can see why loopback alone isn't the whole story and
   when they should set the token.

3. **Posture comparison** — stacks the three network postures
   (fully online / restricted egress / fully air-gapped) side by
   side with red dotted arrows marking the flows explicitly
   blocked at egress in each posture.

4. **Local-LLM provider-slot routing** — shows how setting
   GROQ_BASE_URL (or OPENROUTER_BASE_URL / OPEN_WEBUI_URL)
   redirects the provider slot to Ollama, vLLM, LM Studio, or
   a corporate gateway without touching the console code.

Also adds a short "Local LLM as a security posture" subsection
framing the override as the correct choice for air-gapped and
high-sensitivity environments — not a feature gap. This is
deliberately scoped to the security doc; broader local-LLM
support work lives elsewhere.

No runtime behavior changes. Documentation only.

Signed-off-by: Andrew Anderson <[email protected]>

…DME (#8207)

Fixes #8207

Addresses all 6 Copilot review comments from PR #8203 (security docs
bundle). Verified each claim against source before applying:

- Verified InitializeProviders (pkg/agent/registry.go:283) registers
  only CLI-based tool agents and explicitly excludes API-key HTTP
  providers (claude/openai/gemini/groq/openrouter/open-webui).
- Verified update_checker.go lives in pkg/agent/ (local kc-agent),
  not in the Go backend server pod.
- Verified DEV_MODE is read in cmd/kc-agent/main.go:18 while
  KC_DEV_MODE=1 is only used in pkg/agent/server_http.go:2202 for
  the backend-driven agent restart path.

Changes:

1. README.md (finding #1): The "security model" paragraph no longer
   claims users can point an OpenAI-compatible local LLM at kc-agent
   via GROQ_BASE_URL / OPENROUTER_BASE_URL / OPEN_WEBUI_URL today.
   Reframed as a planned follow-up; currently supported path is the
   CLI-based agents.

2. SECURITY-MODEL.md §1 data flow (finding #2): Replaced the
   single-sentence "Key consequence" block with the two-path
   distinction (CLI tool agents vs direct HTTP providers). Notes
   that CLI agents can exfiltrate cluster data indirectly via
   kubectl/helm tool output; direct HTTP providers are not
   registered at runtime today.

3. SECURITY-MODEL.md §2 Posture B (finding #3): Rewrote the
   restricted-egress section to match runtime reality. AI gating
   is by registered CLI agent availability, not by API-key env
   vars. Setting *_API_KEY does not by itself enable AI. Settings
   → API Keys modal documented as non-operative.

4. SECURITY-MODEL.md §1 "leaves the cluster" (finding #5):
   Corrected the update_checker.go reference. The local kc-agent
   (not the backend pod) performs any GitHub update polling.
   In-cluster backend deployments do not poll GitHub from the
   server pod.

5. SECURITY-MODEL.md §3 Local/Self-hosted LLMs (finding #4):
   Added a prominent "current registration status" subsection
   stating that Groq/OpenRouter/Open WebUI provider implementations
   exist but are NOT registered by InitializeProviders. Relabeled
   the Ollama / vLLM / LM Studio / internal-gateway recipes as
   "planned follow-up" (not operative today). Base-URL env vars
   noted as "parsed, not wired". Retained the mermaid diagrams
   from PR #8206 and framed them as the intended direction.

6. SECURITY-MODEL.md §4 env var cheat sheet (finding #6): Split
   the KC_DEV_MODE row into two entries — DEV_MODE (general
   kc-agent dev/logging toggle, read in cmd/kc-agent/main.go)
   and KC_DEV_MODE (backend-driven restart/dev path in
   pkg/agent/server_http.go) — so operators don't set the wrong
   variable.

Docs-only change. web build + lint pass.

Signed-off-by: Andy Anderson <[email protected]>

…DME (#8207) (#8223)

Fixes #8207

Addresses all 6 Copilot review comments from PR #8203 (security docs
bundle). Verified each claim against source before applying:

- Verified InitializeProviders (pkg/agent/registry.go:283) registers
  only CLI-based tool agents and explicitly excludes API-key HTTP
  providers (claude/openai/gemini/groq/openrouter/open-webui).
- Verified update_checker.go lives in pkg/agent/ (local kc-agent),
  not in the Go backend server pod.
- Verified DEV_MODE is read in cmd/kc-agent/main.go:18 while
  KC_DEV_MODE=1 is only used in pkg/agent/server_http.go:2202 for
  the backend-driven agent restart path.

Changes:

1. README.md (finding #1): The "security model" paragraph no longer
   claims users can point an OpenAI-compatible local LLM at kc-agent
   via GROQ_BASE_URL / OPENROUTER_BASE_URL / OPEN_WEBUI_URL today.
   Reframed as a planned follow-up; currently supported path is the
   CLI-based agents.

2. SECURITY-MODEL.md §1 data flow (finding #2): Replaced the
   single-sentence "Key consequence" block with the two-path
   distinction (CLI tool agents vs direct HTTP providers). Notes
   that CLI agents can exfiltrate cluster data indirectly via
   kubectl/helm tool output; direct HTTP providers are not
   registered at runtime today.

3. SECURITY-MODEL.md §2 Posture B (finding #3): Rewrote the
   restricted-egress section to match runtime reality. AI gating
   is by registered CLI agent availability, not by API-key env
   vars. Setting *_API_KEY does not by itself enable AI. Settings
   → API Keys modal documented as non-operative.

4. SECURITY-MODEL.md §1 "leaves the cluster" (finding #5):
   Corrected the update_checker.go reference. The local kc-agent
   (not the backend pod) performs any GitHub update polling.
   In-cluster backend deployments do not poll GitHub from the
   server pod.

5. SECURITY-MODEL.md §3 Local/Self-hosted LLMs (finding #4):
   Added a prominent "current registration status" subsection
   stating that Groq/OpenRouter/Open WebUI provider implementations
   exist but are NOT registered by InitializeProviders. Relabeled
   the Ollama / vLLM / LM Studio / internal-gateway recipes as
   "planned follow-up" (not operative today). Base-URL env vars
   noted as "parsed, not wired". Retained the mermaid diagrams
   from PR #8206 and framed them as the intended direction.

6. SECURITY-MODEL.md §4 env var cheat sheet (finding #6): Split
   the KC_DEV_MODE row into two entries — DEV_MODE (general
   kc-agent dev/logging toggle, read in cmd/kc-agent/main.go)
   and KC_DEV_MODE (backend-driven restart/dev path in
   pkg/agent/server_http.go) — so operators don't set the wrong
   variable.

Docs-only change. web build + lint pass.

Signed-off-by: Andy Anderson <[email protected]>

…detail (#8210)

Makes the security picture visible in-context at the two moments
users care about — installing the Console itself and installing
a CNCF project via a guided mission. Both surfaces link to the
SECURITY-MODEL.md doc merged in #8203.

Setup install modal (SetupInstructionsDialog.tsx):
- New expandable "Security posture" section next to the Dev
  Guide / K8s Deploy / OAuth sections
- Four subsections covering kc-agent posture, AI key handling,
  what leaves your machine, and the air-gapped / local-LLM
  option (framed as a security posture, not a feature gap —
  deliberately scoped to NOT conflate with the separate broader
  local-LLM support work)
- "Read the full security model" link to docs/security/SECURITY-MODEL.md

Mission Detail view (MissionDetailView.tsx):
- New 5th tab: install / uninstall / upgrade / troubleshooting /
  **security**
- Renders mission.security steps via the existing StepCard
  component
- When mission.security is populated, adds a footer link to the
  overall SECURITY-MODEL.md so users always have a path to the
  full doc
- When mission.security is empty, shows a helpful fallback with
  the global doc link and an "Suggest security notes" button
  (reuses the existing onImprove flow)

Schema (lib/missions/types.ts):
- Adds optional `security?: MissionStep[]` to the MissionExport
  interface. Backwards-compatible.

Locale (locales/en/common.json):
- Adds `missions.detail.tabs.security` and
  `missions.detail.tabs.securityEmpty` strings

Paired with kubestellar/console-kb#2027 which introduces the
schema-side `mission.security` array and populates the first
mission (install-kubevirt).

Signed-off-by: Andrew Anderson <[email protected]>