Permissions and roles
Who can do what in a workspace, how an app's permissions are written as sentences, and how sharing is checked on every request.
Qaldy has three separate layers of "who may". They answer different questions, and each is checked by the system, not by the app.
1. What an app may do#
Every app has a manifest: the exact list of what it reads, which connector actions it uses, which internet addresses it reaches, and whether it uses AI. The plan shows it as sentences, one per permission, and the gate enforces it. If an action is not in the manifest, the app cannot do it. The manifest is immutable per version; a wider one is a new version that needs a new approval.
Read the sentences before you approve. They are the contract. See Build your first app for how the plan reads, and the manifest reference for the fields.
2. Who may open an app#
Each app has a share graph: its owner, the people and teams you added with a role (viewer, runner or editor), and its general access. The gate asks the graph whether this person may open this app on every request. A person who is not allowed is refused with a 403 before any app code runs. When you remove someone, the change reaches the gate within a few seconds. See Share it with your team.
3. What a person may do in the workspace#
Each person has one role, and each role can do what the roles below it can:
- Viewer: looks, and changes nothing.
- Member: opens and runs what is shared with them.
- Builder: makes apps and automations.
- Admin: manages people, connected services and every app.
- Owner: everything, including billing and handing the workspace on.
| What the role can do | Viewer | Member | Builder | Admin | Owner |
|---|---|---|---|---|---|
| Open what is shared, see results | Yes | Yes | Yes | Yes | Yes |
| Run what is shared | Yes | Yes | Yes | Yes | |
| Make apps, automations and backends | Yes | Yes | Yes | ||
| Connect services, approve builds that use a key, read the audit log | Yes | Yes | |||
| Invite people, change roles, remove people | Yes | Yes | |||
| Set the spending cap, hand the workspace over | Yes |
A few rules behind the table:
- Only admins connect services and see the audit log. A key belongs to the workspace, not to whoever pasted it.
- A member's build that uses a connector is approved by an admin. The member sees "Needs an admin to approve" and can send a request.
- Only the owner sets the spending cap and hands the workspace over. A workspace always keeps an owner: the last owner cannot leave or be removed.
- People on a handover end on a date. An agency or freelancer can be a builder, member or viewer, never admin or owner, with an end date both sides can see. When it passes, their access ends.
- Company-domain join admits people as members or viewers only. It never admits a builder, admin or owner.
Tokens and agents#
An agent acts as a person, never as more. A personal access token or an MCP sign-in works in one workspace, carries a read or write scope, and is checked against the person's live role on every call. Anything that changes who has access, spends money or widens an app's reach is refused to a token with console_only or approval_needs_console, and waits for a person in the console. See MCP and the token routes.