1. Docs
  2. Changes and releases
  3. AI Agents

AI Agents

  • AI Agents agent-platform v2.11.0

    Added

    • (muster) Bind mcpserver-editor explicitly to the Giant Swarm admin groups in #232 by @teemow

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v2.10.0...v2.11.0

  • AI Agents muster v5.1.0

    Added

    • (helm) Document the editor RoleBinding trade-off and fail on empty subjects in #1079 by @teemow

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.0.0...v5.1.0

  • AI Agents muster v5.0.0

    Fixed

    • Security (aggregator): a muster without inbound OAuth no longer shares one client’s downstream logins with every other client. Without a bearer token there is no token family to key a session by, so the transport layer injects the default-user placeholder — and that constant was used as the session key, collapsing every concurrent MCP connection onto a single session. Session-scoped state is keyed by that ID: the OAuth token store, the capability store that backs session-scoped tool visibility (ADR 006), and the session connection pool. So once any one client ran core_auth_login against an OAuth-protected backend, that backend’s tools appeared in list_tools for — and were callable by — every other client of the same muster, using the first client’s token. Requests that carry no authenticated identity are now keyed by their MCP transport session instead (one key per client connection, per ADR 006 §4.1); stdio reports a constant session ID, so the inherently single-user stdio transport keeps one stable session. Consequence for unauthenticated HTTP: a session ends with the connection, so a reconnecting client re-runs core_auth_login for its downstream backends. Enable muster’s own OAuth to get durable per-user sessions that survive reconnects. Covered by the session-multi-user-progressive-auth and session-multi-user-tool-isolation scenarios, whose isolation assertions previously passed vacuously (see below).
    • Test framework: expected.not_contains is now evaluated for test_* steps. The scenario loader accepted the field and the regular tool path implemented it, but the test-tool path only logged a warning and passed, so every absence assertion written on a test_* step was vacuous — including the session-isolation assertions in session-multi-user-progressive-auth and session-multi-user-tool-isolation, which is why the leak above went unnoticed. It now fails the step when the response contains an unexpected string, matching the non-test-tool path.
  • AI Agents muster v4.1.1

    Fixed

    • Helm: values.schema.json no longer rejects valid chart values. podDisruptionBudget.minAvailable accepts a percentage string ("50%") as well as an integer, podDisruptionBudget.maxUnavailable is now a declared value (the PDB template already honoured it, but the schema refused it as an unknown key), and the free-form gatewayAPI.httpRoute.{labels,annotations} / gatewayAPI.backendTrafficPolicy.{labels,annotations} maps accept arbitrary keys. Setting any of these previously failed at helm install/helm template time with values don't meet the specifications of the schema(s).
  • AI Agents agent-platform v2.10.0

    Added

    • (muster) Turn on the MCPServer connection-state alerts in #231 by @teemow

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v2.9.0...v2.10.0

  • AI Agents muster v4.1.0

    Added

    • (reconciler) Export MCPServer connection state as metrics and alert on sustained failure in #1076 by @teemow

    Full Changelog: https://github.com/giantswarm/muster/compare/v4.0.0...v4.1.0

  • AI Agents agent-platform v2.9.0

    Changed

    • components.muster.versionRange default changed from "3.x" to "4.x". muster v4.0.0 (muster#1075, muster#1069) routes Workflow spec mutations (core_workflow_create/_update/_delete) through the same caller-identity gate MCPServer writes got in v2.0.0: in Kubernetes mode the write carries the session’s own dex id_token, authorized by k8s RBAC via the chart-shipped workflow-editor role (bound to all authenticated users by default, mirroring mcpserver-editor). No installation needs to act: sessions already must carry the dex-k8s-authenticator audience for MCPServer writes since the 2.x crossing (same gate, same token), the workflow-editor Role/RoleBinding ships in the muster chart itself, and no fleet installation overrides rbac.mcpServerEditor or disables muster rbac.create (checked via org-wide code search). The crossing also fixes core_workflow_update on Kubernetes installations — the old path sent an update without a resourceVersion, which the apiserver rejects for CRs, so the tool never worked there.
  • AI Agents muster v4.0.0

    Added

    • (workflow) [breaking] Write workflow spec mutations with the caller’s own identity in Kubernetes mode in #1075 by @teemow

    Full Changelog: https://github.com/giantswarm/muster/compare/v3.0.1...v4.0.0

  • AI Agents muster v3.0.1

    Changed

    • (aggregator) Delete the unenforced destructive-tool denylist and –yolo in #1074 by @teemow

    Full Changelog: https://github.com/giantswarm/muster/compare/v3.0.0...v3.0.1

  • AI Agents agent-platform v2.8.0

    Changed

    • components.muster.versionRange default changed from "0.x" to "3.x". muster crossed three majors inside this unreleased window; the range now resolves the current line. No installation needs to act for any of them — the specifics below. First crossing: muster crossed a major with #968 (feat(oauth)!: remove JWT mode) — muster no longer signs tokens; dex is the sole SSO authority. The 0.x default has kept every non-overriding installation frozen on muster 0.24.0 since the 1.0.0 bump, so they never received the 1.x line (including the #37164 SSO re-exchange deauth fix first released in muster v1.0.7). Every fleet installation already runs dex-only (shared-configs sets none of the removed keys — enableJWTMode/jwtSigningKey/localMint/M2M), and alligator already runs 1.0.7 healthy, so the jump is safe. Upgrade note: crossing into muster 1.0.7+ re-authenticates every user exactly once (the mcp-oauth bump changes the Valkey token-storage layout with no legacy read-fallback); existing sessions do not carry over. Second crossing, muster v2.0.0 (muster#1064): the writesAsCaller transition gate is gone, so in Kubernetes mode session-initiated MCPServer mutations (create/update/delete and CR-driven start/stop/restart) always write with the caller’s own dex id_token, authorized by k8s RBAC via the chart-shipped mcpserver-editor role (bound to all authenticated users by default). Sessions must carry the dex-k8s-authenticator audience and the apiserver must trust dex OIDC — already true fleet-wide. The gate lived two hours and no installation ever set it. Third crossing, muster v3.0.0 (muster#1072, muster#1067): type: stdio MCPServers are rejected in Kubernetes mode — a stdio server is started as a subprocess of the muster pod, so accepting one made “may write MCPServer resources” mean “may execute code in the muster pod as muster’s ServiceAccount”. Validate/create/update fail the tool call; a stdio CR applied with kubectl reconciles to status.state: Failed and is never started. Nothing to migrate: no gitops manifest in the org and no live installation declares a type: stdio MCPServer (all are streamable-http), which is also why this crossing did not need to be a major. Should one ever be needed, run the MCP server as its own workload and register it with type: streamable-http or sse; stdio still works when muster runs as a local CLI.