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.
Who can talk to an agent
The roles above decide who can see and change a deployment. Who can use the deployed agent is a separate decision, made per interface: the web interface and Slack each carry their own access list, so the same agent can be open on one and restricted on the other.
A request is allowed only when it matches an entry on that interface’s list, and you can mix entry types.
Grant an interface access from the agent’s Configure screen. Granting the web interface does not grant Slack.
An agent whose interface has no entries at all falls back to letting members of the owning account in. Adding any entry to that interface turns the fallback off, so the list becomes the only way in.
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 grayed 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
- Audiences: keep one list of people and grant several agents access to it
- Working with accounts: account roles and switching between accounts
- Manually authorize requests: run these same checks yourself from an agent
