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

AI Agents

  • AI Agents agent-platform v4.140.0

    Changed

    • The installation’s skills credential follows the tenant credential naming convention. The agent-manager component’s range starts at 2.3.0 (>=2.3.0 <3.0.0) and the migrate run’s BOM pin is 2.3.0: with agent-manager.skills.mintGitAuthSecret agent-manager mints tenant-credential-agent-manager-skills-token, composes it onto every git-skill agent and keeps its earlier name agent-manager-skills-token filled. The connectivity chart’s agent-manager migrate run gets the current name and the earlier ones (AGENT_MANAGER_SKILLS_GIT_AUTH_SECRET_NAME, AGENT_MANAGER_SKILLS_GIT_AUTH_PREVIOUS_SECRET_NAMES, derived as agent-manager’s chart derives them, agent-manager.skills.previousGitAuthSecretNames included) and moves every agent naming an earlier name to the current one once that Secret exists; a GitOps-owned agent gets the diff in the run’s report. Nothing is done by hand; the earlier Secret keeps working until no agent names it. make verify-migration asserts the run’s inputs.
  • AI Agents muster v5.43.0

    Fixed

    • muster auth login signs in again when the server rejects a stored token that has not expired. A token file whose access token was unexpired by its stored expiry but rejected by the server (the server dropped the session) made the login print Establishing SSO connections... and exit 0 without a browser, a sign-in URL or a token, --force included, and muster auth status stayed Not authenticated until the stored expiry passed. The login now checks the session with the server after reusing the stored one and runs the browser (or --no-browser) flow when the server still answers 401; --force always runs the flow. The command exits 0 only once the server accepts the session, and with exit code 3 when a completed flow leaves none; --server and --all sign in to the aggregator the same way. (#1484)
  • AI Agents agent-platform v4.139.0

    Added

    • A ModelConfig in an Organization namespace names only a tenant credential; the platform’s copied Secrets are written only by agent-manager. With kagent on, the ValidatingAdmissionPolicy agent-platform-tenant-model-credentials (Fail, bound with Deny) refuses, in every namespace labelled giantswarm.io/organization but the kagent namespace and for every requester, a ModelConfig (any served version) whose spec.apiKeySecret is not a tenant-credential-* Secret, the prefix an EgressPolicy’s secretKeyRef already keeps there. The exception is agent-manager’s tenant reconciler (agent-manager on and tenants.organizations.enabled), which writes the copy of the platform’s default ModelConfig. A ModelConfig without apiKeySecret is admitted. With agent-manager on and tenants.organizations.enabled, agent-platform-tenant-platform-secrets (Fail, Deny) lets only the reconciler’s ServiceAccount create, update or delete a Secret in those namespaces that carries its label agent-manager.giantswarm.io/tenant-object (before or after the write) or is named as the default ModelConfig’s key Secret (kagent.providers.<default>.apiKeySecretRef); the namespace and garbage collectors may delete one, so a namespace can still go. Every other Secret there, the tenant’s tenant-credential-* ones included, stays with RBAC. agent-platform-tenant-platform-secret-refs (Fail, Deny, same switches) refuses there, for every requester, an Agent or AgentTemplate whose skill or plugin git source names the copied model key Secret as credentialRef, and a RemoteMCPServer whose headersFrom names it as a Secret; other Secrets stay referable (agent-manager names the installation’s skills credential). A key Secret named with the tenant-credential- prefix fails the render. An installation with an Organization’s own ModelConfig on a Secret without the prefix renames that Secret to tenant-credential-<name> before the step; the existing ModelConfig keeps working until its next update. make verify-tenant-rbac asserts both policies’ shape. Needs Kubernetes 1.30 or later.

    Fixed

    • The kagent namespace’s EgressPolicies are no longer readable by every signed-in person. agent-platform:user read egresspolicies.api.kagent.dev in every namespace that binds it, and the kagent namespace binds it to tenants.platform.users (default system:authenticated), so the platform tenant’s egress origins and the names of the Secrets they use were listed to everyone. The kagent namespace now binds tenants.platform.users to the new ClusterRole agent-platform:platform-user, agent-platform:user without EgressPolicies, through the RoleBinding agent-platform:platform-user; the RoleBinding agent-platform:user there is removed by the step (a binding’s role cannot change in place). A tenant’s agent-platform:user, :editor and :admin keep the read in their namespace; the kagent namespace’s editors keep it there. make verify-tenant-rbac asserts it.
  • AI Agents agent-platform v4.138.0

    Added

    • tenants.organizations.enabled also turns on agent-manager’s tenant reconciler (giantswarm/agent-platform#1044). With agent-manager on, its release gets tenants.enabled: true (it starts with --multi-tenant), the kagent namespace’s default ModelConfig default-model-config with its key Secret (kagent.providers.<default>.apiKeySecretRef), the workers’ network policy (substrate-workers on Cilium, substrate-workers-ingress on the kubernetes flavor, none with networkPolicy.enabled off) and 1 warm worker for each tenant that holds an agent as tenants.workerPoolReplicas (agent-manager.tenants.workerPoolReplicas overrides it). The render fails, naming the key, with an agent-manager range below 2.1.0, kagent off, agent-manager’s OAuth or downstream OAuth off, an empty kagent.fluxServiceAccountName, a default provider without apiKeySecretRef, or agent-manager.tenants.enabled set against the switch. Off, agent-manager’s values do not change. make verify-tenant-reconciler.

    Refactored

    • make verify-flux-crds, verify-substrate-store, verify-wiring and verify-metric-labels pass on macOS too. Their recipes no longer need GNU sed -i, GNU sed’s 0,/re/ address, grep -P or an unpadded wc -l, so they run with the BSD tools of a Mac as on CI. They check the same things.
  • AI Agents agent-platform v4.137.0

    Added

    • A codex Harness entry and its egress origins, per installation, off by default (giantswarm/giantswarm#38552). A kagent.harnesses entry takes runtime: codex: the kagent chart renders a Harness on its codex-harness image at the published digest, with the entry’s own name, snapshot location and env and no limits, beside a claude one. The entry’s origins, the installation’s forge and git hosts, go under agent-manager.harness.egress.<Harness name>: agent-manager writes them into a codex agent’s spec.egress, the Substrate egress gate refuses every other origin with a 403, and kagent adds the model destination itself. kagent refuses a share of a Session on a codex Harness, as on every coding Harness. Nothing renders without the values. values.yaml shows the entry, ci/test-coding-agents-values.yaml carries a codex entry beside the claude one with both egress lists, and make verify-kagent-harness and make verify-components-charts assert the forwarded entries, the codex Harness at the chart’s codex-harness digest against the pinned Harness CRD, and agent-manager’s egress map with an entry for every coding Harness.

    Changed

    • components.kagent.versionRange and components.kagent-crds.versionRange are >=1.13.0 <1.14.0 (were >=1.12.0 <1.13.0), and the customer BOM pins kagent 1.13.0: a harnesses[] entry runs the codex runtime (giantswarm/kagent-upstream#606). The kagent chart publishes the codex-harness image and stamps its digest into runtimeImages.codexHarness, and a harnesses[] entry takes runtime: codex; the 1.12 chart refused it. The codex runtime reports a turn’s usage on its final task status (giantswarm/kagent-upstream#610). The release also publishes the omp-harness image, which no harnesses[] runtime selects yet. Same upstream pin, no CRD, API or persisted-format change: Substrate stays on 1.11.4, and every conversation carries over (UPGRADE.md).
  • AI Agents agent-platform v4.136.0

    Added

    • A Responses API ModelConfig for codex through the LLM listener (giantswarm/giantswarm#38551). The codex runtime speaks OpenAI’s Responses API only, and the listener’s ModelConfigs followed the first llmRouting.models entry’s provider alone, so a codex agent’s model calls went to the provider directly, unpriced and outside the rate limits. Every llmRouting.models provider now rides the listener: an OpenAI entry (baseURL: https://api.openai.com/v1, match: gpt-*) serves the Responses route the data plane classifies at /v1/responses, and a kagent.modelConfigs[] entry of that provider gets the listener URL with /v1, the base an OpenAI client appends /responses to. A new apiFormat key (chatCompletions or responses, OpenAI only, refused elsewhere naming the entry) sets openAI.apiFormat; with responses and no other OpenAI option the ModelConfig passes the codex compiler’s rules. The MutatingAdmissionPolicy renders once per served provider, so a codex ModelConfig agent-manager or Backstage creates rides the listener too (<release>-modelconfig-llm-routing-openai; the first provider’s keeps its name). llmRouting.rateLimits target the listener, so they cover the Responses route as every other. A codex call appears under its agent in the usage metrics once the codex runtime names its agent on its model calls (giantswarm/kagent-upstream#613); until then it reads unknown. make verify-llm-routing.
  • AI Agents agent-platform v4.135.0

    Changed

    • components.agent-manager.versionRange is >=2.1.0 <3.0.0 (was >=1.13.0 <2.0.0), the connectivity release’s agent-manager migrate run takes agent-manager 2.1.0, and the customer BOM pins it. get_session answers a bounded summary by default (detail: full for every task) beside the new get_session_turn and delete_session (giantswarm/agent-manager#150, #155); get_info lists in namespaces.managed only the namespaces where the caller may create agents (giantswarm/agent-manager#71); an agent on a claude Harness without a harness.egress entry is refused, naming the entry (giantswarm/agent-manager#148). The tenant reconciler ships off (agent-manager.tenants.enabled). Supersedes giantswarm/agent-platform#1001.
  • AI Agents agent-platform v4.134.0

    Fixed

    • Vertex AI with a service account key works under Cilium enforcement: Substrate’s credential provider reaches oauth2.googleapis.com:443 (giantswarm/agent-platform#1042). The provider exchanges an AnthropicVertexAI or GeminiVertexAI ModelConfig’s service account key for an access token itself, at the key’s token_uri, but substrate-k8s-credential-provider allowed only DNS and the apiserver, so every Vertex AI call failed with could not exchange the service account key for an access token. The policy now opens networkPolicy.substrate.credentialProvider.egressFQDNs on 443/TCP, with the DNS proxy rule that lets Cilium match the names; the default is oauth2.googleapis.com, the only token_uri kagent admits. A list of its own replaces the default; [] leaves the provider the apiserver and DNS only. The kubernetes flavour renders no egress policy and ignores it. make verify-kagent-netpol asserts the default, a list of its own and an empty one.
  • AI Agents muster v5.42.3

    Changed

    Fixed

    • (aggregator) ForwardToken tools resolve on a session’s first call in #1517 by @teemow
    • (deps) Update module github.com/valkey-io/valkey-go to v1.0.79 in #1516 by @renovate[bot]

    Full Changelog: https://github.com/giantswarm/muster/compare/v5.42.2...v5.42.3

  • AI Agents muster v5.42.2

    Fixed

    • The Kubernetes watch’s startup listing no longer drops change events. At startup the detector emitted one event per existing MCPServer and Workflow into a 100-slot channel that the reconcile manager read only after the listing had synced, so on an installation with 289 Workflows everything past the first 100 was dropped with a Change event channel full WARN each, and a real change arriving during the listing could be lost the same way. The manager now drains the channel before the detector starts, and the detector waits for room instead of dropping, until it stops; each informer handler has its own unbounded buffer, so the wait paces only that handler. (#1469)