Administer access from the CLI¶

dbt Charts Cloud

This page describes dbt Charts Cloud, the hosted product — these features are not part of the open source dct engine.

Everything the Access settings pages do is also a dct cloud verb, so a script, a CI job, or an agent can answer "can Sam open finance?", onboard a team to a folder, or export the audit log without a browser. Each verb calls the same Cloud API the pages use and gives the same answer; see Access control for how grants, inheritance, and public access work.

Every verb takes --json (the raw API response), --org, and --host. Verbs that act on a project also take --project. audit export always prints JSON or CSV, so it takes --format instead of --json.

Who can run what¶

A token's scope is a ceiling: the person who signed in must also be an org admin. dct cloud login asks for all of these.

Scope	Verbs
`orgs:admin`	`access list`, `check`, `grant`, `revoke`, `remove-here`, `restore`, `inherit`, `stop-inheriting`, `general`; `public`; `member show`; `audit list` and `export`; `team`; `role`; `identity groups`
`connections:admin`	`connection access list`, `grant`, `revoke`

Who may open a board is an organization matter, so every access verb needs orgs:admin; the projects:admin scope covers project settings only.

A verb the token's scope does not cover fails with a 403 naming the scope.

Check who can open what¶

dct cloud access list --project analytics --who sam@acme.com
dct cloud access check --project analytics --who sam@acme.com --path finance/revenue

--who is an email, a team slug, or group:<id> for an identity group, exactly what the Check access page accepts. access check prints the verdict and the grants behind it, and its exit status says the answer:

Exit	Meaning
0	allowed
1	denied
2	the check could not run (bad project, unknown person, no credential)

access list narrows like the Grants page: --project, --who (an email, a team slug, or group:<id>), --role, and --public. member show <email> prints a member's teams, identity groups, grants, and every board they can open.

Change access¶

Verb	Effect
`access grant --who W --path P --role R`	Give W a role at P
`access revoke --who W --path P`	Take back the grant W holds directly at P
`access remove-here --who W --path P`	Remove W's access at P, inherited access included
`access restore --who W --path P`	Undo `remove-here`
`access stop-inheriting --path P`	P keeps who can open it now; later changes to its parent folders stop reaching it
`access inherit --path P`	P inherits its parent folders' grants again
`access general restricted\\|org\\|public --path P`	Pick who beyond the named grants can open P

A blank --path is the project root; a folder ends in /. general org lets everyone in the organization view P; general public lets anyone with the link view it and needs both public gates on:

dct cloud public list
dct cloud public allow                      # the organization's gate
dct cloud public allow --project analytics  # one project's gate

Teams, roles, identity groups, connections¶

dct cloud team create "Revenue Ops"
dct cloud team add revenue-ops --member sam@acme.com
dct cloud role create analyst --name Analyst \
  --entitlement dashboards.view --entitlement dashboards.edit
dct cloud identity groups --provider acme.okta.com   # read-only
dct cloud connection access grant warehouse --who revenue-ops --role editor

role edit replaces the name and the whole entitlement list. Identity groups are read-only because the identity provider owns their membership. The "everyone in the org" default on a connection is set on the connection's page, not here.

Audit log¶

dct cloud audit list --actor admin@acme.com --project analytics
dct cloud audit export --format csv --since 2026-10-01T00:00:00Z > audit.csv

audit list filters by --since (ISO 8601), --actor, --action, and --project, and pages with --page and --limit. audit export follows every page and writes one JSON array or one CSV with the columns id, created_at, actor, action, project, and summary. Adding someone to a team or removing them is in the trail too, since it changes who holds every grant the team holds.

Scripting examples¶

Onboard a team to a folder:

dct cloud team create "Revenue Ops"
for email in sam@acme.com riley@acme.com; do
  dct cloud team add revenue-ops --member "$email"
done
dct cloud access grant --project analytics --path finance/ \
  --who revenue-ops --role viewer
dct cloud access check --project analytics --who sam@acme.com \
  --path finance/revenue && echo "Sam can open finance/revenue"

Fail a CI job when a public board appears:

test "$(dct cloud public list --json | jq '.grants | length')" -eq 0

Export last week's audit log:

dct cloud audit export --format json \
  --since "$(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ)" > last-week.json

On macOS, use date -u -v-7d +%Y-%m-%dT%H:%M:%SZ.