Buildkite links a cloud control plane to self-hosted agents that run jobs inside an organization's network. That split is useful for build performance and infrastructure control, but it creates two different security questions. Who can change a pipeline, and which agent token can receive work for a cluster? A web-page search can identify public Buildkite surfaces, but it cannot answer either question without asset ownership and authentication context.

What the measurement shows

A count-only ZoomEye query was run on 2026-11-11 at 23:48 UTC with sub_type=all, page 1, and page size 1. The query title="Buildkite" returned 42 matches. The same collection recorded app="Buildkite" at 0 and http.body="Buildkite" at 933.

The title count is the most useful starting point because it is narrower than a body search and specific enough to reduce unrelated results. It is still a page-title observation, not a census of Buildkite organizations. A login page, documentation mirror, status page, or customer portal may share the term. The zero application-fingerprint result is a reminder that ZoomEye's app field is not a complete product inventory.

Why tokens define the practical risk

Buildkite documents separate access tokens for the REST API and agent tokens for self-hosted agents. API tokens can be scoped to platform features, while agent tokens register agents and can be constrained by cluster and queue. The Buildkite security checklist recommends the lowest pipeline permission that works and asks teams to review cluster assignments, agent-token expiry, and connected or stopping agents.

A token that can register an agent is not merely a monitoring credential. It can place a new worker into a queue that receives jobs, potentially including jobs with repository access or deployment keys. A token with broad pipeline permissions can alter what code runs. The severity depends on the token scope, queue, cluster, and the secrets available to jobs.

Review order for an owned deployment

Begin with the organization's own inventory. Identify every agent token, its cluster and queue, its expiry, and the last agent registration. Remove tokens that have no owner or no recent use. Confirm that an agent cannot join a privileged queue merely because it knows a generic registration endpoint. Keep trusted jobs on a dedicated queue with a separate token and restrict which pipelines can target that queue.

Next, review the Buildkite API tokens. List the scopes, owners, creation dates, and last use. Separate read-only reporting from tokens that can create builds, change pipeline settings, or access package registries. A GraphQL-enabled token deserves extra review because the documentation describes it as a full-access option without the narrower feature scopes.

Finally, review pipeline permissions. A user who can edit a pipeline can often influence the code and credentials used by its agents. Compare the organization's role assignments with the pipeline's actual sensitivity. Require review for changes to build steps, plugins, environment hooks, and signing keys.

What ZoomEye can add

For an organization with known domains, ZoomEye can help find public Buildkite pages that appear outside the expected inventory. Use the vendor name as a discovery clue, then verify the owning organization and the page content before treating it as a Buildkite deployment. Do not scan or attempt authentication against assets that the organization does not own.

Matching a Buildkite title does not prove that an agent is reachable, that a token is exposed, or that a pipeline is vulnerable. It is an inventory observation. The useful action is to compare the observation with DNS ownership, approved cloud domains, and the organization's own Buildkite settings.

References