dbt package v1.0.0

A dbt service account token for the customer's own account, held in the client's own secret manager. The stored material must be the complete Authorization header value — scheme, one separating space, then the token — and the injector injects the stored value verbatim. Header format: the fetched user-tokens page explicitly shows personal access tokens used as 'Authorization: Bearer <your-token>'; the fetched service-tokens page does not state the wire scheme for service account tokens, so 'Bearer <token>' is registered here as the expected-but-unverified scheme for service tokens and must be confirmed against the live reference before enabling.

Issuance: service tokens are created in Account settings > Service Tokens by an account admin, are shown only once at creation, belong to the account rather than to any user, and carry the permission sets the issuer assigns.

Least privilege: assign the minimum permission sets for the capabilities actually enabled — dbt's own sets map cleanly (Read-only or Job Viewer for the reads, Job Admin for job create and update, Job Runner for triggering runs) — and scope them to specific projects rather than all projects where the deployment allows; Account Admin tokens have full read+write on the account and this pack does not need one.

Expiry and revocation: the reviewed documentation describes no automatic expiry — a token remains valid until it is deleted in Account settings, and dbt's rotation guidance is to create a replacement token with the same permissions, put it in place, and only then delete the old token; older tokens remain valid until deleted, so disabling the ability to create new tokens does not invalidate already-issued ones.

Rotation ownership sits with an external deployment process; the executor performs no token lifecycle itself. Personal access tokens (which inherit a human user's permissions) are documented for individual use — prefer service account tokens for this integration so access does not track one employee's account.

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.

The endpoint host 'dbt-cloud.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's own dbt access URL before enabling — dbt serves the Administrative API from the account's unique access URL — current dbt accounts are issued cell-based prefix URLs (for example abc123.us1.dbt.com; emea.dbt.com for EMEA multi-tenant, au.dbt.com for APAC, and vanity URLs for single-tenant/VPC deployments), listed in Account settings below the Account information pane, while the legacy multi-tenant host cloud.getdbt.com is documented as slated for future removal, in every endpoint, in the resource locator and in every egress allowlist entry; the allowlist matches exactly, so all three must be substituted together, and substitution is a required deployment step.

ACCOUNT_ID, JOB_ID and RUN_ID in the endpoint paths are placeholders the deployment binds to concrete resources before enabling. Triggering a job run is treated as deploy-equivalent in this pack: a dbt job run compiles and executes the project's models against the target data platform — it changes what the warehouse serves — so dbt.job.run.trigger registers the deploy action at the minimum R3 tier, not as an ordinary execute.

This pack registers Administrative API v2 routes only: dbt documents v3 as the recommended newer API with a smaller route set, and the deployment should re-review when migrating. The interactive v2 endpoint reference (docs.getdbt.com/dbt-cloud/api-v2) is a client-side-rendered explorer that did not yield retrievable operation content in this review; the registered routes follow the long-documented v2 URL shapes (jobs, runs, environments, POST .../jobs/{id}/run/ to trigger, POST .../jobs/{id}/ to update, POST .../runs/{id}/cancel/ to cancel) and each route was verified on 2026-09-21 against the retrieved dbt documentation and corroborating official sources listed in the review block (see the review record).

Scheduled execution is provider-side: a job's cron schedule fires inside dbt Cloud and never traverses an AAES capability, which is exactly why job create and update themselves declare the deploy action — dbt.job.run.trigger governs manual API triggers only.

Excluded operations: service account token or personal access token issuance and deletion (credential lifecycle stays in Account settings under direct human control), user invitation and group or permission-set management, connections (which carry warehouse credentials — writing a connection writes the database sign-in itself), repository and git credential management, account settings and billing, audit-log access, run artifact downloads (artifacts contain compiled SQL and run results — sensitive payloads deserving their own review), the Discovery (metadata) API, the Semantic Layer API, and all v3 endpoints.