Access control
Resources are private. Deployments, private blueprints, and knowledge stores are reachable only by people who have been given access to them. Belonging to the organization grants nothing on its own, and there is no setting that restores blanket access for all members.
This page explains the model. To put it to work, see Manage access with groups.
Where access comes from
Three sources feed into one decision, and a person gets the sum of all three.
Access is a union, so the most permissive source wins. Adding a grant never takes access away.
An account member is not locked out of the product. Members create resources, and the creator becomes the Admin of whatever they create. What a member does not get is access to resources somebody else made.
Permissions
A permission is a single action. Roles exist because permissions are tedious to hand out one at a time, but the permission is what actually gets checked.
Permissions do not imply one another. edit does not include read, and a role that looks higher on the ladder is higher only because it bundles more.
Roles
Each resource type uses the same four rungs, and each rung adds to the one below it.
Select Access on a deployment or private blueprint to assign these roles. On desktop, the access panel opens beside the control. On mobile, it opens as a bottom sheet.
Maintainer is the rung that shares, Admin is the rung that destroys. Grant Maintainer to someone who should run a resource day to day, and keep Admin for the people who should be able to remove it.
What appears in a list
A list shows only the resources you can read. This is the same check as opening one, applied to every row, so a deployment a teammate created and never shared does not appear in your deployment list at all. It is not hidden behind a lock icon; it is absent.
Public blueprints are the exception and are always listed, whether or not you belong to the account that owns them.
If you expect to see something and don’t, you need read on it. Ask someone with Maintainer or Admin on that resource, or an account administrator, to grant it.
When access is denied
The response depends on what was denied.
A resource-level denial returns 404 rather than 403 on purpose. A 403 would confirm that the resource exists, which leaks the names of things you cannot see. The tradeoff is that a real typo and a real permission problem look identical, so check the identifier before assuming it is access.
503 is worth handling separately in a script. It means the decision could not be made, not that the answer was no, so retrying is correct where retrying a 404 is not.
When a change takes effect
Access changes apply immediately. Nobody needs to sign out, and no token has to expire first: each request is authorized against current access.
The web console caches permission checks briefly, for about 30 seconds, and refreshes them when the window regains focus. So a button may stay greyed out for a few seconds after someone grants you a role. The underlying access is already live; reload if you don’t want to wait.
Buttons in the console are enabled only after the server confirms you hold the permission. That check is a convenience, not the enforcement: every action is authorized again when you actually take it.
Personal accounts
A personal account has one member, who is its administrator and reaches everything in it. There is nobody else to grant access to, so access panels do not appear. The model is unchanged, it just has nothing to decide.
Next steps
- Manage access with groups: grant these roles to a team at once
- Working with accounts: account roles and switching between accounts
- Manually authorize requests: run these same checks yourself from an agent