Roles and permissions

Every member of a K-Block organization has exactly one role: Owner, Admin, Approver, Developer or Viewer. The role decides what that person may read and change in the dashboard and through the Cloud API.

The Cloud API enforces these rules on every request. It checks your role again each time, so a role change or a removal takes effect on your next request. The dashboard hides controls your role cannot use, but hiding a control is only a convenience: the server is the authority.

Use this page to choose a role when you invite someone, to understand a 403 refusal, and to pick the scopes of a management API key.

The five roles

The person who creates an organization becomes its first owner. Invitations can grant any role except Owner; an owner promotes someone to owner after they have joined (see The last owner).

Developer is for one user. Team membership starts with Startup. The free Developer plan (the plan, not the developer role) has room for one member, the owner, and invitations are refused, so every task in the matrix below falls to the owner, including deciding approval requests when the rule admits owners (see Who may approve). To give people roles, an owner moves the organization to Startup or a larger plan on Billing.

Permission matrix

"Yes" means the role may do it. "Rule" means the role may do it only when the approval request's approver rule admits that person (see Who may approve).

Reading

Building and integrating

Putting things into service and stopping them

Organization administration

K-Block does not offer organization deletion in this version: there is no API route and no dashboard control for it.

Fine-grained rules

The matrix gives the coarse picture. A few rules depend on what is being changed, not only on who changes it.

Developers draft, owners and admins put into service

Anything that changes what a policy or a delegation decides on needs an owner's or admin's consent:

• Tools. A developer can create tools, but they are always created disabled, as drafts. Asking to create one enabled is refused with 403 ADMIN_REQUIRED. Only an owner or admin can enable a tool or authorize its upstream binding. While a tool is enabled, a developer cannot change its action, exposed name, amount mapping, currency pointer or description; disable it first. A developer can still disable an enabled tool, and can edit its input schema. Editing the schema of an enabled tool changes its binding, so the Gateway hides the tool and refuses its calls with TOOL_REAUTHORIZATION_REQUIRED until an owner or admin re-authorizes it.
• Agents. A developer can create an agent with any policy and edit its name, description, status and KID, but switching an existing agent to a different policy needs an owner or admin.
• MCP servers. A developer can change the URL, server KID or credential of a server only while none of its tools is enabled. When an owner or admin changes them, the server's enabled tools need re-authorization before they can be called again.
• Policies. A developer can write drafts, set or clear the shadow version, edit examples and save simulations. Activating a version, rolling back and the emergency stop are owner and admin actions.

For the tool and agent rules, and for activation, rollback, emergency stop and disclosure, K-Block checks your role again at the moment it saves the change. If you are demoted while a slow request is still running, the change is refused.

Who may approve

Deciding an approval needs all of the following, checked when you submit the decision:

1. Your role is Owner, Admin or Approver. Developers and viewers can never decide.
2. You are signed in. Management API keys can never decide.
3. The policy rule that asked for approval admits you, either by your role or by your user ID. Every require_approval rule must name its approvers. When no rule matches and the policy's default is require_approval, all three approval roles are admitted.
4. You sign with a K-Block identity (KID) that is bound to your account, is not revoked, and was already listed as an approver when the request was created.

Consequences worth knowing:

• Owners and admins are not automatically approvers. A rule that lists only the approver role refuses an owner.
• A promotion after the request was created does not add you: your KID is not on the request. A demotion below an approval role removes your right immediately, because the role is read again.
• An identity you bind after the request was created is not on the request either.
• Every enabled member the rule admits who has an active identity is listed on the request, with at most 32 KIDs in total. When the admitted members hold more than 32 identities, each member keeps at least their newest one, but not every identity is listed. If nobody matches, the call is denied with NO_APPROVERS; if more than 32 members match, with TOO_MANY_APPROVERS.
• K-Block has no separation-of-duties rule in this version. Nothing stops the admin who activated a policy, or the owner who signed the agent's delegation, from approving a request the rule admits them to.

An approval request's page in the dashboard uses the server's own eligibility answer for that request, so it shows a decision control only when you can decide. See Review and decide.

The last owner

An organization must always keep at least one enabled owner:

• Only an owner can grant the owner role, change an owner's role or remove an owner. An admin who tries gets 403 OWNER_REQUIRED.
• The last enabled owner cannot be demoted, removed or leave. The request is refused with 409 LAST_OWNER. A disabled owner account does not count as a remaining owner. A disabled account shows a Disabled badge on Members; accounts are disabled by K-Block, not from the dashboard or through the Cloud API.
• To hand over ownership, make the new person an owner first, then change your own role or leave.

On the Members page, the last enabled owner's role is shown as plain text, and their own row says "Make another member owner before leaving." instead of offering Leave. The page can only tell once every page of members is loaded; if a change still reaches the server, it is refused with 409 LAST_OWNER and the page shows "The member change was refused".

Admins have no special protection from each other: an admin can promote a member to admin and can demote or remove another admin.

Who signs delegations and cancellations

A delegation authorizes the Gateway to act for an agent; a cancellation stops an action that is pending approval or approved but has not run yet. Both are signed in the browser with the organization's principal key, and the server verifies the signature against the organization's principal identity.

• Only an Owner can set up the organization's principal identity.
• Submitting or revoking a delegation and cancelling an action need the Owner or Admin role and a signed-in session. In practice the person also needs their own copy of the principal key in their browser. To hand it over, an owner exports a key backup that contains the principal, and the admin or other owner imports it in their own browser, signed in to their own account. A copy that another account stored in the same browser profile is not used for them.
• A removal, or a demotion below admin, does not take back a copy of the key. Such a person can no longer submit delegations, revocations or cancellations themselves (an owner demoted to admin still can), but their copy still signs as the organization: outside K-Block those signatures verify, and until the principal is replaced K-Block accepts them from anyone who is an owner or admin, including someone they give the copy to. If that matters, an owner replaces the principal (see Settings).

See Identities and KIDs and Delegations.

What removal and demotion withdraw

When a member is removed, leaves, or is demoted, K-Block withdraws what they can no longer hold, as part of the same change:

Each revocation and each disabled endpoint is recorded in the audit log with the reason.

API keys also stop working on their own if their creator loses the role needed to create them, because the creator is checked at every use (see API keys).

Management API key scopes

A management API key acts for scripts, not people. What it may do comes from its scopes, never from a role, and it can only reach the organization it belongs to. It works only while the person who created it is still an owner or admin (see API keys).

A write scope never lets a key do what a developer cannot. These are always refused for management keys, whatever their scopes: deciding approvals, cancelling actions, submitting or revoking delegations, activating, rolling back or emergency-stopping policies, starting observe windows, changing disclosure, anything about members, invitations, API keys or webhooks, reading the audit log, changing organization settings, setting the principal identity and changing the plan.

A key from another organization gets 404. A key without a needed scope gets 403 FORBIDDEN with details.required_scope. A key used on a route keys can never use gets 403 FORBIDDEN with the message "API keys cannot do this; sign in instead" or "this endpoint requires a signed-in user".

Refusals you may see

See Error codes for the full catalogue.