Buildkite releases scoped secrets and MCP tools for AI in CI/CD

Secrets tied to the pipeline, not the whole cluster

Buildkite announced on October 19, 2026, according to an InfoQ report, a new secrets view within Pipeline settings. It allows creating "pipeline secrets": cluster secrets whose access is restricted to the current pipeline, instead of appearing in the cluster's general interface, visible to all pipelines that use it. You can add conditions by branch, queue, build source, or build creator, and the secret's value disappears from the screen as soon as it's saved.

Pipeline secrets are cluster secrets restricted to the current pipeline, and branch, queue, build source, or creator conditions narrow access further.

Matt Mejia, in Buildkite's announcement

To create or edit these secrets, you need permission both on the pipeline and on cluster management. Pipelines that use the GitHub Actions compatibility layer now display a warning, before the first workflow runs, pointing to the secrets configuration.

Reduced scope doesn't eliminate the need for care within the step

Separating secrets by pipeline reduces the exposure radius of a leak, but Buildkite itself acknowledges, in the documentation cited by InfoQ, that this doesn't replace the care of exposing each secret only to the steps that actually need it. InfoQ had already reported, in 2025, HashiCorp advocating for "prevention-first" secrets management in development tools and CI/CD systems, and this is the same problem that Buildkite is now tackling from the interface side.

The change package ties up more loose security ends. The Buildkite CLI gained a command to migrate secrets from GitHub Actions, and version 3.59.1 fixes the handling of relative workflow paths during this migration. Agent v4.0.9 now masks Buildkite tokens by prefix in job logs, and v4.0.8 masks captured job errors using the secrets already registered for that job.

An MCP server to validate, compare, and fix pipelines

The most extensive part of the announcement is the update to Buildkite's open source MCP server, designed to give AI agents CI-specific tools instead of forcing them to parse entire logs or build low-level API calls. The validate_pipeline tool checks the syntax and structure of the pipeline's YAML against Buildkite's official schema without uploading the file or triggering a build, returning paths and error messages that a coding agent can use to fix invalid steps. It doesn't cover environment variable interpolation, plugin configuration, cross-dependency references, or dynamically generated steps.

The second tool, compare_builds, compares a failed build with the most recent prior build that passed on the same branch, or with another build chosen manually. It points out which steps started failing, which recovered, and which remain broken, along with changes in runtime and retries; for up to three newly broken steps, it brings the end of the job log as immediate diagnostic context. As InfoQ's coverage summarizes, just having access to the log isn't enough to debug a build, and that's exactly the gap compare_builds tries to close, giving the agent a comparison point instead of a text dump.

The MCP release also adds Test Engine execution traces and queries for the slowest runs, and brings the create_pipeline_webhook tool, which adds a missing GitHub webhook to an already existing pipeline, avoiding recreating it from scratch.

Breaking change for those automating MCP

Version 1.23.0 of the server changed the behavior of create_pipeline: it's now mandatory to explicitly provide create_webhook, which breaks integrations that called this tool without that parameter. Teams that automated pipeline creation via MCP need to review these scripts before updating.

Buildkite also reversed a design decision after running evaluations: failure summaries now once again include jobs that never ran, because leaving that optional made agents issue extra tool calls to find out the same information. It's a small detail, but it shows the company adjusting the MCP API based on how agents actually behave, not on how the team imagined they would behave. Remote MCP connections can now also be pinned to a single Buildkite organization directly in the server URL, both for the full URL and the read-only one.

What changes for those building pipelines here

In practice, a coding agent gains the ability to run validate_pipeline before the commit, catching a syntax error in the pipeline's YAML without spending an entire CI build just to find out a quote mark was missing. After something breaks, compare_builds gives the agent, and whoever is on call, a structured diff between the problem build and the last one that passed, instead of forcing someone to scroll through two hundred lines of log looking for what changed.

The same warning InfoQ already made for agentic workflows on GitHub applies here: giving an agent tools that create webhooks or create pipelines is giving it permission to alter CI configuration. The model of restricted permissions, isolated execution, and auditable actions that InfoQ described for agentic workflows on GitHub also applies here, especially for those planning to let MCP run without human oversight on every call.

arm64 arrives in the GitHub Actions compatibility layer

The compatibility layer that runs GitHub Actions workflows inside Buildkite now supports Linux arm64 agents for both the importer and the generated jobs. Labels like ubuntu-24.04-arm require explicit queue mapping and don't fall back to x86-64 or use emulation, which matters for those who maintain an arm64 fleet (Graviton instances on AWS, for example) and want to keep that architecture when bringing GitHub Actions workflows into Buildkite.

The compatibility package also fixes environment values, named secrets, runtime variables, and matrix values in service-container configuration, exposes more strategy.* values for job and step expressions, and raises the limit of changed files used by path filters from 300 to 3,000, useful for large monorepos that previously hit that ceiling.

More telemetry in Agent v4.1.0

Agent v4.1.0 adds cache save and restore duration and size to Buildkite's telemetry, and OpenTelemetry job spans now include commit, pull request, and build author. These are extra fields for those who already instrument their pipeline with OpenTelemetry and need to investigate a slow job or retry pattern: Buildkite cites the case of Pinterest, which used Honeycomb together with Buildkite to separate agent wait time from script execution time and identify jobs behind build-time spikes.

Agent v3 has a deadline to exit the stage

Elastic CI Stack v7, released alongside these changes, brings Agent v4 to Linux and Windows instances on AWS, removes support for Agent v3, and retires or replaces some tracing and cancellation parameters. Buildkite recommends reviewing custom parameter files, deploy automation, and values passed via AgentEnvFileUrl before updating. Support for all Agent v3 versions ends on September 3, 2027, giving those running Elastic CI Stack on AWS nearly a year to plan the migration without rushing.