circleci v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-circleci-personal-api-token

Custody

customer_vault

Injection

header (Circle-Token)

A CircleCI personal API token, held in the client's own secret manager. The stored material must be the complete Circle-Token header value: the token itself, with no scheme prefix added. CircleCI documents the Circle-Token header as the primary API v2 authentication, and also accepts RFC 6750 bearer and HTTP Basic (token as username, blank password) forms; the query-parameter form is deprecated and must not be used. CircleCI documents that personal API tokens grant full read and write access as the owning user with no scope reduction available, and that project API tokens are not supported on API v2 — so the only least-privilege control available is a dedicated token on an account with the minimum project access, and nothing broader; review that account's permissions before enabling. CircleCI documents no token expiry: deleting the token in user settings is the revocation path and invalidates that issued token, and rotation means deleting and recreating it. Renewal ownership sits with an external deployment process: the executor injects the stored value verbatim and performs no token lifecycle itself, and it must never substitute a different credential without an approved pack change. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• circleci-project (api, internal): https://circleci.com/api/v2/project/PROJECT_SLUG

The registered host is circleci.com (CircleCI cloud). Self-hosted CircleCI server installations use an installer-specific host: substituting it into the endpoints, the resource locator and the egress allowlist is a pack change that requires re-review before enablement. PROJECT_SLUG, PIPELINE_ID, WORKFLOW_ID and APPROVAL_REQUEST_ID in the endpoint paths are placeholders the deployment binds to concrete values per request target (PROJECT_SLUG is the vcs-slug/org-name/repo-name triple, for example gh/example-org/example-repo); the registered paths do not change. This pack registers only endpoints the public CircleCI API v2 documentation and its published OpenAPI specification describe: reading one project, listing a project's pipelines, listing a pipeline's workflows, listing a workflow's jobs, triggering a pipeline, and approving a pending approval job. Documented exclusions: the newer recommended pipeline-run endpoint (which the provider documents as superseding the registered trigger), pipeline continuation, workflow rerun and cancel, job cancel, schedule and trigger management, contexts, environment variables, project settings, checkout keys, webhooks, organization administration, and every endpoint outside the registered list — a documented exclusion, not an approximated capability; each addition is a pack change and requires its own review. Integration scope of the registered trigger: CircleCI's current trigger documentation distinguishes projects on the GitHub OAuth app and Bitbucket Cloud integrations from projects on the newer GitHub App, GitLab and Bitbucket Data Center integrations, which are served by the newer pipeline-run model; the registered legacy trigger fits the former, and a well-formed PROJECT_SLUG alone does not establish compatibility — confirm the project's integration type in the CircleCI web app before enabling. Tiering rationale: reads sit at the R0 floor. pipeline.trigger is registered as deploy at the R3 floor because CircleCI documents that the request body lets the caller choose the branch or tag and pass pipeline parameters, and CircleCI pipelines commonly perform deployments — deploy is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). job.approve is registered as approve at the R3 floor because an approval job is the documented gate before protected continuation of a workflow, commonly a deployment, and the approval is recorded under the caller's identity — approve is one of the IRREVERSIBLE ACTIONS. AAES has not been certified by CircleCI; reviewable default, not a vendor guarantee.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://circleci.com/docs/api/v2/ (retrieved 2026-09-21)
• https://circleci.com/api/v2/openapi.json (retrieved 2026-09-21)
• https://circleci.com/docs/managing-api-tokens/ (retrieved 2026-09-21)
• https://circleci.com/docs/triggers-overview/ (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.