dbt 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-dbt-service-token

Custody

customer_vault

Injection

header (Authorization)

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. Scheme honesty: 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 fetched 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.

• dbt-cloud-account (api, internal): https://dbt-cloud.invalid/api/v2/accounts/ACCOUNT_ID

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 region-specific access URL (the default multi-tenant host is cloud.getdbt.com, and Enterprise accounts may have a different one), 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 R3 floor, 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 could not be retrieved verbatim in this review session; 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 must be re-verified against the live reference before enabling — one reason this pack stays in draft state. 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 verb — dbt.job.run.trigger governs manual API triggers only. Documented exclusions — this pack does not register: 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.

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

• https://docs.getdbt.com/docs/dbt-cloud-apis/admin-cloud-api (retrieved 2026-09-21)
• https://docs.getdbt.com/docs/dbt-cloud-apis/service-tokens (retrieved 2026-09-21)
• https://docs.getdbt.com/docs/dbt-cloud-apis/user-tokens (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.