Continuous integration provider Buildkite has rolled out pipeline-scoped secrets that restrict credential access to individual pipelines, alongside new Model Context Protocol tools designed to let AI agents validate configurations, diagnose failed builds, and repair broken webhooks. The company also introduced Linux arm64 support for its GitHub Actions compatibility layer and expanded OpenTelemetry data in Agent v4.1.0, according to an announcement published this month. The updates address multiple points where credentials can be exposed or misconfigured in CI workflows.
Engineers can now create cluster secrets whose access is limited to the current pipeline from a new secrets view under Pipeline settings, rather than managing all credentials from the broader cluster interface. Teams can attach conditions that narrow access further based on branch, queue, build source, or build creator, and secret values stay hidden once they're created. The Buildkite CLI includes a command for migrating GitHub Actions secrets, with version 3.59.1 fixing how relative workflow paths are handled during migration. Agent v4.0.9 redacts Buildkite tokens by prefix in job logs, while v4.0.8 redacts captured job errors using secrets registered for the job. GitHub Actions pipelines now show a prompt that links to secret configuration before their first workflow runs.
The most substantial feature additions appear in Buildkite's open-source MCP server, which now offers a validate_pipeline tool that checks pipeline YAML syntax and structure against Buildkite's official schema without uploading it or triggering a build. It returns paths and error messages that an AI coding agent can use to fix invalid steps, though the check doesn't cover environment variable interpolation, plugin configuration, dependency references, or dynamically generated steps. A second tool, compare_builds, contrasts a failed build with the most recent earlier successful build on the same branch or with another selected build, reporting steps that have newly failed, recovered, or stayed broken, along with changes in runtime and retries. For up to three newly failing steps, it includes the end of the job log to give an agent immediate diagnostic context. The MCP release also adds Test Engine execution traces and slowest-execution queries, while another tool, create_pipeline_webhook, can add a missing GitHub webhook to an existing pipeline without recreating it. Version 1.23.0 changed create_pipeline so that callers must specify create_webhook, which is a breaking change. Remote MCP connections can now be pinned to one Buildkite organisation by adding it to the server URL.
Matt Mejia writes in Buildkite's announcement that the change "keeps pipeline-specific secrets together" while showing how many other secrets the cluster manages, and that users need permission both to edit the pipeline and manage its cluster. He notes that "pipeline secrets are cluster secrets restricted to the current pipeline, and branch, queue, build source, or creator conditions narrow access further." Mejia also observes that "log access alone does not debug a build," explaining why the company built discrete validation, comparison, and repair tools to reduce agents' reliance on parsing full logs and composing lower-level API calls.
The work fits into a broader push for prevention-first secret management across developer tools and CI/CD systems that HashiCorp was advocating in 2025, according to the report. Buildkite's own documentation advises teams to expose a secret only to the steps that require it, and scoped storage doesn't eliminate the need to control how credentials are used inside steps. Permissions remain important because webhook repair and pipeline creation can modify CI configuration, similar to a security model for GitHub agentic workflows that's based on isolated execution, restricted permissions, and auditable actions. Giving agents discrete tools for validation, comparison, and repair should reduce the risk of misconfiguration while making diagnostic workflows more efficient.
Buildkite's GitHub Actions compatibility layer can now run its importer and generated jobs on Linux arm64 agents, allowing organisations with arm64 CI fleets to keep that architecture when bringing compatible Actions workflows to Buildkite. Labels such as ubuntu-24.04-arm require an explicit queue mapping and don't fall back to x86-64 or emulation. Other compatibility fixes resolve environment values, named secrets, runtime variables, and matrix values in service-container configuration, and Buildkite has also exposed more strategy.* values to job and step expressions. The changed-file limit used by path filters has risen from 300 to 3,000, alongside a fix for push workflows where a branch moved after the original push. Agent v4.1.0 adds cache save and restore durations and sizes to Buildkite telemetry, with OpenTelemetry job spans now including the commit, pull request, and build author. These fields add context for teams investigating slow jobs or retry patterns, building on work Pinterest previously described using Honeycomb with Buildkite to separate agent waiting time from script execution and identify jobs behind build-time spikes. The associated Elastic CI Stack v7 release brings Agent v4 to Linux and Windows instances on AWS, removes Agent v3 support, and retires or replaces some tracing and cancellation parameters. Buildkite advises users to review custom parameter files, deployment automation, and values supplied through AgentEnvFileUrl before upgrading, with support for all Agent v3 releases ending on 3 September 2027. The combination of scoped secrets, agentic tooling, and expanded telemetry should give teams finer-grained control over credential exposure and faster paths to diagnose build failures. Platform teams adopting AI-assisted CI workflows will need to balance the efficiency gains from automated validation and repair against the governance risk of giving agents write access to pipeline configuration.