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

AI Agents

  • AI Agents muster v5.12.1

    Fixed

    • (oauth) A pinned authorization server is the one key of a server’s grants and its pin is released when the MCPServer changes in #1177 by @teemow

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.12.0...v5.12.1

  • AI Agents agent-platform v3.11.0

    Added

    • muster.muster.toolsetPresets: the platform’s two toolset presets, forwarded into muster’s config. infrastructure selects every MCPServer labelled agent-platform.giantswarm.io/tool-group=infrastructure (the mcp-kubernetes, mcp-capi and mcp-prometheus families, stamped by agent-platform-mcps ≥ 0.9.0); agent-platform selects the agent-platform label (agent-manager ≥ 0.3.0, model-manager ≥ 0.18.0) plus muster’s core_* tools — the meta agent’s preset. Agents name them as preset:infrastructure / preset:agent-platform in their toolset; muster resolves the label live on every request, so a new manager or infrastructure family joins its preset with no values change. Installations add their own next to them (Helm merges the map). A preset named like a built-in (read-only, none, full) fails the meta render, naming it, instead of failing the muster pod’s start out of sight. Documented in docs/toolset-presets.md; make verify-presets asserts the presets on the muster HelmRelease (both engines), pulls the muster chart at the range floor and renders its ConfigMap from the forwarded values.

    Changed

    • components.muster.versionRange floors at 5.12.0 (>=5.12.0 <6.0.0, was 5.x): the muster chart version with the label: preset rule. An older muster refuses to start on the shipped presets, so the source must resolve a chart that has the rule before the release applies the values that need it. Minor releases keep rolling forward on their own. BOM-pinned installations pin muster at 5.12.0 or later (UPGRADE.md).
    • examples/customer-bom.yaml is a fresh snapshot of the internal dogfooding track (muster 5.12.0, agent-platform-mcps 0.9.0, agent-manager 0.4.0, model-manager 0.18.0, agentgateway 2.0.7, kagent 0.1.48, klaus-gateway 0.39.0, agent-sandbox 0.2.31, dicebear 0.3.10, valkey 0.1.4, connectivity 3.10.0); the previous pins predated the chart’s current line.
  • AI Agents muster v5.12.0

    Added

    • (toolset) Label: preset selector — a preset rule selects the tools of every MCPServer whose resource carries the label, read live in both storage modes; MCPServerInfo carries labels; harness labels and test_set_mcpserver_labels in #1171 by @teemow

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.11.0...v5.12.0

  • AI Agents muster v5.11.0

    Added

    • (metatools) Per-request toolsets — X-Muster-Toolset header, toolsetPresets, filter_tools toolset argument, annotation forwarding, workflow read-only derivation in #1170 by @teemow

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.10.3...v5.11.0

  • AI Agents klausctl v0.3.3

    Fixed

    • (version) Report the release version instead of “dev” (pkg/project, stamped by CI and the Makefile) in #341 by @teemow

    Full Changelog: https://github.com/giantswarm/klausctl/compare/v0.3.2...v0.3.3

  • AI Agents agent-platform v3.10.0

    Added

    • kagent.oauth2ProxyIngress.additionalPeers (default []), in both charts: extra callers the kagent oauth2-proxy ingress policy admits on the proxy port (4180) next to the public Gateway’s Envoy pods — a list of pod label maps (matchLabels), each rendered as one more fromEndpoints entry (cilium flavor; the kubernetes flavor renders no oauth2-proxy policy). A peer in another namespace carries its own io.kubernetes.pod.namespace; an item that is not a non-empty label map fails the render. For an installation whose kagent hostname sits on a private edge LB and whose kagent API is reached from elsewhere through a Teleport tunnel: the local teleport-kube-agent (app: teleport-kube-agent in kube-system) proxies the tunnel’s requests to oauth2-proxy and was dropped by the policy, so the tunnel hung without an HTTP answer. make verify-kagent-netpol covers it. No installation needs to act: the default render is unchanged.
  • AI Agents agent-platform v3.9.0

    Added

    • gitops.forbidInlineSecrets (default false): with true the meta-package render fails when a credential is set inline in the values — kagent.providers.<name>.apiKey, kagent.oauth2-proxy.config.clientSecret / .cookieSecret, muster.muster.oauth.server.dex.clientSecret / .google.clientSecret / .registrationToken / .encryptionKeyValue / .storage.valkey.password, valkey.valkey.auth.aclUsers.<user>.password, klausGateway.slack.botToken / .signingSecret / .appToken, klausGateway.obo.stateKey / .storeKey, model-manager.oauth.dex.clientSecret, agent-manager.oauth.dex.clientSecret — and names the offending key paths (never their values). Such a value is forwarded verbatim into the component’s HelmRelease spec.values (Argo: valuesObject) and into Helm’s release storage, readable by anyone allowed to get HelmReleases in gitops.namespace; every component chart takes the same credential from a pre-created Secret instead (kagent providers.<name>.apiKeySecretRef with an empty apiKey and oauth2-proxy.config.existingSecret, muster oauth.server.existingSecret and .storage.valkey.existingSecret, valkey auth.usersExistingSecret, klaus-gateway slack.secretName with an empty botToken and obo.existingSecret (klaus-gateway >= 0.39.0), model-manager / agent-manager oauth.existingSecret). The values.yaml guidance for those keys now recommends the pre-created Secret, and klausGateway.obo.existingSecret is documented next to the keys it replaces. make verify-secrets (in CI) pins the default, the failure and the referenced-Secret render. No installation needs to act: the flag is off and the default render is unchanged; an installation that has moved its credentials into Secrets sets it to true so they cannot come back.
  • AI Agents agent-platform v3.8.1

    Changed

    • The CNPG Cluster’s CiliumNetworkPolicy (<clusterName>-cluster) selects the pods of a Cluster named <clusterName>-restore as well — the scratch Cluster a restore test bootstraps from the backup store (bootstrap.recovery + externalClusters[].plugin). Its full-recovery Job needs the Kubernetes API and the object store, which the CNPG operator’s cluster-wide policies (instance, initdb, join pods) do not grant to recovery Jobs; without this the restore Job times out on the API server. Name a scratch restore Cluster exactly <clusterName>-restore (the Crossplane IAM role already trusts <clusterName>-restore*). No installation needs to act.

    Fixed

    • Documented in the README: enabling postgres.backup on a Cluster that is already running rolls its instance pods to add the plugin sidecar, and the immediate first Backup fires before the sidecar exists and fails with requested plugin is not available; the next scheduled run (or a manual Backup with method: plugin) succeeds. A Cluster created with the block from the start does not hit this.
  • AI Agents agent-platform v3.8.0

    Added

    • postgres.backup.* in both charts: backups for the CNPG Cluster the connectivity chart renders, off by default. method: plugin (the default) wires the Barman Cloud plugin — CNPG’s supported object-store path since 1.26, the one the in-tree barmanObjectStore is deprecated in favour of — as the Cluster’s WAL archiver and renders an ObjectStore (<clusterName>-backup: destinationPath, optional endpointURL for S3-compatible stores, exactly one credential source out of s3.inheritFromIAMRole, static S3 keys, azure.inheritFromAzureAD, an Azure connection string or account+key Secret references, gzip WAL/data compression, retentionPolicy default 30d, sidecar resources) and a ScheduledBackup (<clusterName>-scheduled, default daily at 02:00 UTC, immediate, backupOwnerReference: self). method: volumeSnapshot renders backup.volumeSnapshot on the Cluster instead (no WAL archive). serverName overrides the folder in the store, objectStore.existingName reuses a store, serviceAccount.annotations binds the Cluster’s ServiceAccount to a cloud identity (IRSA role, workload identity) for the sidecar. In the cilium flavor the CNPG policy gains egress for the store (DNS, world on networkPolicy.ports, the cluster entity for an in-cluster endpointURL, optional fqdns and cidrs). postgres.backup.crossplane.* (off) provisions the store the way the fleet provisions its own object storage: on aws an S3 Bucket with a lifecycle rule, a public-access block and a TLS-only policy plus an IAM Role whose trust policy names the cluster’s IRSA OIDC provider for the Cluster’s ServiceAccount and <clusterName>-restore* (scratch restore clusters), with destinationPath, s3.inheritFromIAMRole and the role annotation derived; on azure a Storage Account, a Container, a lifecycle ManagementPolicy and, on private installations, a PrivateEndpoint in the node subnet, with destinationPath and azure.connectionString derived from the Account’s connection Secret (<clusterName>-backup-store). Bucket, Account and Container are never deleted by Crossplane and carry helm.sh/resource-policy: keep. Guards fail the render on a missing or foreign destinationPath, zero or several credential sources, IRSA without a role annotation, a bad method, retentionPolicy or storage-account name, a snapshot method without a class and missing Crossplane inputs. make verify-postgres covers it; ci/test-postgres-values.yaml (MinIO shape), ci/test-postgres-backup-aws-values.yaml and ci/test-postgres-backup-azure-values.yaml render it. No installation needs to act, but every installation with postgres.enabled and no postgres.backup should: its Cluster now carries agent-platform.giantswarm.io/backup: none and NOTES warns that the PVCs are the only copy of the platform database. A CNPG Cluster without a backup still reports ContinuousArchiving=True/ContinuousArchivingSuccess — the operator’s wal-archive command exits 0 when there is nowhere to archive to — so that condition is not a signal.
  • AI Agents agent-platform v3.7.3

    Fixed

    • The kagent cilium network policies open egress from the kagent controller and from the kagent-managed agent pods to kagent’s built-in tool server when it is enabled (kagent.kagent-tools.enabled: true): the app.kubernetes.io/name: kagent-tools pods in the tools namespace on the tools port (8084; an explicit kagent.kagent-tools.namespaceOverride / service.ports.tools.targetPort is honoured). kagent-controller-egress and kagent-agent-muster-egress are default-deny egress lists, so the controller’s tool discovery (MCP initialize + tools/list on the kagent-tool-server RemoteMCPServer URL) and the agents’ tool calls were dropped as Policy denied: the RemoteMCPServer stayed Accepted=False and every agent that referenced it ran without tools. Nothing renders for installations with the tool server off (the default). make verify-kagent-netpol (in CI) pins the rules both ways.