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

AI Agents

  • AI Agents muster v5.9.1

    Fixed

    • core_auth_logout now finds the server’s authorization server when the registry entry does not know it yet. The entry learns the issuer from the connection probe’s 401 or from a login’s discovery, so after a muster restart it is empty for a backend that publishes no RFC 9728 metadata until someone logs in – while the person’s tokens from before the restart are still in the store. Logout skipped every token step in that state and answered “Successfully logged out” with the tokens (for a grantScope: subject issuer: the person’s grant) in place, and did not recognise sibling servers on the same issuer. It now resolves the issuer like a login does – spec.auth.authorizationServer.issuer, else the server’s resource metadata – and matches siblings by their pin as well. Test framework: mcp_servers[].config.oauth.omit_resource_metadata makes the mock backend answer a bare 401 and serve no well-known document.
  • AI Agents muster v5.9.0

    Fixed

    • Subject-scoped grants serve every session of the person on first use. For an MCPServer whose authorization server has grantScope: subject, a session that never called core_auth_login for it – another MCP client, a fresh CLI session, a front-end whose bearer rotated, any session after a muster restart with the grant persisted – is connected with the person’s existing grant by the tool call itself, and list_tools shows the server’s tools to it instead of listing the server under auth_required. Before, only core_auth_login reused the grant: a plain tool call from such a session failed with user not authenticated to server <name> (or tool not found while no session of the process had connected the server), so every client had to know to call core_auth_login on that error. Concurrent first calls from one session share a single connection; a grant the server rejects with 401 is cleared for the person, as core_auth_login does, so the next login issues a fresh sign-in link. Sessions of a person without a grant fail as before. The same lookup also lets a session that is already authenticated to a server whose authorization server is pinned (spec.auth.authorizationServer, no discovery document) rebuild its connection after a muster restart from the pinned issuer; before, the tool call failed with unable to determine auth method for server <name> until the session ran core_auth_login again.
  • AI Agents muster v5.8.4

    Fixed

    • core_auth_logout on a server whose authorization server has grantScope: subject now revokes the person’s grant even when other MCPServers share the issuer. The shared-issuer guard – which rightly leaves a session-scoped token alone when several servers depend on it – also skipped the clear for a subject-scoped issuer, so with GitHub’s hosted MCP server and an in-house server both pinned to https://github.com/login/oauth, logging out of either answered “Successfully logged out” while the session token and the person’s grant stayed in the store and the next core_auth_login reconnected without a prompt; the grant could only expire or be revoked on GitHub’s side. The logout now deletes the tokens for the issuer from every session of the person and from the grant, disconnects every server of the issuer (auth mark, cached capabilities, pooled connection) in the calling session and in the person’s other live sessions, tells those sessions their tool lists changed, and names the sibling servers it disconnected in the tool result. A session-scoped shared issuer keeps the previous behaviour. Test framework: mcp_servers[].config.oauth.grant_scope pins the referenced mock OAuth server as the MCPServer’s authorization server with that grant scope.
  • AI Agents muster v5.8.3

    Fixed

    • The aggregator’s registry entry for an MCPServer now carries the resource’s own namespace. No registration path passed metadata.namespace on, so every server was filed under default: a clientCredentialsSecretRef (spec.auth.authorizationServer or spec.auth.tokenExchange) that named the MCPServer’s own namespace logged a spurious Cross-namespace secret access ... from MCPServer in namespace default warning on every core_auth_login, and the token-forwarding, token-exchange and authentication-loss events muster files for the server were attached to an MCPServer of that name in default. The warning now fires only when the Secret is read from a namespace other than the MCPServer’s; which Secret is read is unchanged. core_mcpserver_get and core_mcpserver_list report the namespace in Kubernetes mode.
  • AI Agents klaus v0.0.321

    Changed

    Full Changelog: https://github.com/giantswarm/klaus/compare/v0.0.320...v0.0.321

  • AI Agents klaus v0.0.320

    Fixed

    Full Changelog: https://github.com/giantswarm/klaus/compare/v0.0.319...v0.0.320

  • AI Agents muster v5.8.2

    Fixed

    • muster serve with kubernetes: true no longer falls back to filesystem mode when the Kubernetes client cannot be created at startup. The fallback was silent (one debug-level line) and left muster split in two: the reconciler’s change detector still watched the apiserver, so every existing MCPServer CR arrived as a create event, was looked up in the empty config directory as “not found” and had its service deleted (Deleting MCPServer service: … for each CR), while the orchestrator’s auto-start listed zero definitions — muster served no server tools, and the CRs kept their stale Connected status because the status writes went to the filesystem as well. It happened after a node restart, when the muster container came back before the apiserver (and the kube-proxy rules in front of it) did and the CRD discovery call failed. Startup now retries the client for about half a minute (client.KubernetesClientBackoff, each attempt logged) and then exits with kubernetes mode is configured but no Kubernetes client could be created … refusing to fall back to filesystem mode, so the kubelet restarts the container; the change detector also takes its mode from the client that was actually created rather than from the configuration flag, so the two can no longer disagree. Automatic detection (no configured mode) keeps the fallback, now logged at warning level. (#1143)
  • AI Agents muster v5.8.1

    Fixed

    • (deps) Bump golang.org/x/crypto to v0.56.0 (CVE-2026-56855) in #1146 by @teemow

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.8.0...v5.8.1

  • AI Agents klaus-operator v0.0.147

    Changed

    Full Changelog: https://github.com/giantswarm/klaus-operator/compare/v0.0.146...v0.0.147

  • AI Agents agent-platform v3.7.1

    Changed

    Full Changelog: https://github.com/giantswarm/agent-platform/compare/v3.7.0...v3.7.1