ECLI-014: Buildkite PR builds may execute branch-controlled code on a Vault-capable agent

**Severity: Medium**

### Problem

[catalog-info.yaml:41](https://github.com/elastic/cli/blob/main/catalog-info.yaml#L41) sets `build_pull_requests: true`. The following code path then executes during PR builds without any repository-level contributor guard:

1. [.buildkite/pipeline.yml:51](https://github.com/elastic/cli/blob/main/.buildkite/pipeline.yml#L51)
— Cloud smoke tests are triggered from the pipeline without a branch or
contributor check.
2. [.buildkite/run-cloud-tests.sh:24](https://github.com/elastic/cli/blob/main/.buildkite/run-cloud-tests.sh#L24)
— runs branch-controlled `npm ci`, followed by the branch-controlled build.
3. [.buildkite/run-cloud-tests.sh:35](https://github.com/elastic/cli/blob/main/.buildkite/run-cloud-tests.sh#L35)
— sources branch-controlled `.buildkite/setup-env.sh`.
4. [.buildkite/setup-env.sh:18](https://github.com/elastic/cli/blob/main/.buildkite/setup-env.sh#L18)
— invokes Vault and writes a Cloud admin key to `~/.elasticrc.yml`.

If fork or otherwise untrusted PR builds run on an agent that is authorized for that Vault path, no nvm or jq compromise is required: the attacker modifies `setup-env.sh`, `package.json` lifecycle code, or build scripts in their PR branch and directly retrieves or exfiltrates the Vault credential.

Repository code does not show whether PR agents can authenticate to Vault. Confirm the fork-build policy, agent identity, Vault role, and agent reuse settings in Buildkite and Vault.

### Fix

- Ensure untrusted PR code cannot execute with a Vault-capable identity. Confirm fork behavior, build-source conditions, agent identity, and Vault authentication in Buildkite administration. A `build.source == "pull_request"` condition in `.buildkite/pipeline.yml` is branch-controlled code: a malicious PR can remove it. Enforce the gate in protected Buildkite configuration (e.g., a pipeline-level trigger condition, agent queue selection, or a Vault authentication policy that rejects PR build tokens), not in repository-controlled pipeline files.
- If PR Cloud tests are required, require maintainer approval and use a separate, narrowly scoped test credential and Vault role. Do not expose the Cloud administration credential to branch-controlled code.
- Restrict the Vault identity's policy to exactly `secret/ci/elastic-cli/cloud-access`. Keep only the credential required by this job at that dedicated path; `-field=api_key` is client-side output selection, not field-level Vault authorization. Store the expected path in protected Buildkite configuration to prevent accidental redirection, but do not treat the variable as an authorization boundary: branch-controlled code with the Vault identity can ignore it and invoke `vault read` directly.
- Use single-use, ephemeral agents for every build that accesses Vault.

### Risk

**Medium on currently demonstrable facts; potentially Critical if confirmed.**
If fork PR builds execute branch-controlled scripts on agents authorized for Vault, treat as Critical and disable secret access for PR builds immediately. The file-mode gap (ECLI-013) and the nvm bootstrap gap (ECLI-003) are secondary to this boundary question.

---
Copied from the [security review](https://github.com/elastic/infosec/issues/27626#issuecomment-5172341916) in elastic/infosec#27626 (ECLI-014).