Skip to main content
Access in Fused is granted per resource, not per person’s good intentions. A team can be allowed to use a bucket-backed app without being allowed to read what is in the bucket. This page covers granting that access and checking it before you need it.

​
Roles and grants

A workspace role sets the baseline. Grants narrow or extend it per resource. Every one of these commands takes the same three things in the same order: the team, the resource, then the level. The command words are fixed; everything in <angle brackets> is yours to fill in. Swap grant for revoke to take access away, with the same three arguments. The workspace role is clear rather than revoke, and it takes no level: workspace team access workspace clear <team-slug-or-id>. So for a team whose slug is payments:
Activation permissions come with Admin and Owner; Builder and Viewer do not carry them. What each level actually buys: App levels apply to every version of that app.
Bucket manage includes bucket.values.read. That is the line this whole page exists to draw — use lets a team build on a credential they can never read, and manage hands them the credential. Grant use unless someone genuinely needs to administer the secrets.
App grants use the stable APP_ID from fused-cli app list. This identifies the app across all its versions and distinguishes apps that share a name across types.

​
Check before you plan

Preflight the owning team against every dependency, so a plan does not fail halfway through on a missing grant.
Replace the file path with the app config whose owning team you are checking. build-access lists what is available to both you and the team — which is the set that will actually work.

​
Share with the whole workspace

When the audience really is everyone, a workspace-wide grant beats maintaining a grant per team.
This gives every authenticated member and eligible owning team bounded use. Ownership does not move, secrets stay unreadable, and lifecycle and token management stay where they were. Revoke removes only that global binding — owner and explicit team bindings survive.
A workspace-wide app grant does not replace the runtime token. Callers still need a valid execution token.

​
Flags

​
workspace access list

​
team build-access

​
workspace team member add

​
workspace team create

​
When you are denied

Stop. Keep the config and plan you had prepared, and report the exact missing permission and resource. Do not self-grant, switch credentials, or retry with broader authority — a scoped service.manage grant does not include the workspace-level workspace.update that applying activation needs, so guessing tends to produce a second confusing failure rather than a fix.

Store credentials in a bucket

Access decides who may select a bucket. The bucket decides what credentials they get to use without seeing.