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

AI Agents

  • AI Agents klausctl v0.2.56

    Changed

    Full Changelog: https://github.com/giantswarm/klausctl/compare/v0.2.55...v0.2.56

  • AI Agents klaus v0.0.322

    Changed

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

  • AI Agents agent-platform v3.7.2

    Changed

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

  • AI Agents muster v5.9.3

    Fixed

    • muster test no longer terminates the instances of another muster test running at the same time. The start-up sweep for instances left behind by an earlier run matched every muster serve --config-path .../muster-test-... process on the machine and sent each one SIGTERM, so a second suite started in another terminal – or the harness’s own unit tests under go test ./internal/testing/, which called the sweep for real – killed the first suite’s instances: scenarios then failed with muster instance process exited (code 0) before becoming ready, or an instance shut down cleanly mid-scenario. The sweep now terminates only instances whose parent muster test process is gone (re-parented after a crash or kill), which is the case it exists for; instances of a live harness are left alone, and the unit tests run the sweep against a fabricated process table plus two stand-in processes of their own.
  • AI Agents muster v5.9.2

    Fixed

    • (aggregator) Tool calls resolve an OAuth server’s issuer themselves — a session whose authenticated flag outlived a restart no longer fails with ‘unable to determine auth method’ in #1151 by @teemow

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.9.1...v5.9.2

  • 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