How Klarify AI applies your permissions
When you connect an AI client to Klarify, the client inherits your Klarify role — it can do only what you can do in the app. For the underlying role model, see Permissions and roles.
Tool visibility by role
Klarify exposes a small set of workflow tools and adapts that set to the signed-in user.
| Access | Additional tools available |
|---|---|
| Guest | Identity, capability discovery, organization profile, and folders |
| Full member | Search and read documents; find employees, positions, members, and invitations; read permitted organization structure |
| Editor, Global Task Editor, or Global Editor | Manage document visibility and folder placement, limited to content the user can edit |
| Org Admin, Super Admin, Account Manager, or Account Owner | Manage people, organization structure, and CSV imports, with each selected action checked against the specific admin role |
How role enforcement works
Role checks happen on the MCP server, not in the AI client. A broad tool can contain actions that require different roles, so seeing a tool does not mean every action inside it is available. The server checks the requested action and rejects anything beyond the user’s access.
For example, an Org Admin can use organization-structure tools but cannot read SSO and login settings. Those settings require Account Manager, Super Admin, or Account Owner access, matching the Authentication settings in Klarify.
How write actions are approved
When you ask the AI to make a change — create a position, update an employee, delete a team — the change is not applied immediately. Each write is intercepted and shown to you as an approval card describing the exact action and its values. The change runs only after you approve it; approving the card is your consent for the specific values shown.
A few behaviors follow from this:
- One action at a time. If you ask for several changes in a single message (“create a department and a team”), the AI proposes them one approval card at a time rather than all at once.
- Deletions that would orphan data ask first. Before deleting an employee who holds positions, or a position that owns documents, the AI asks how to reassign that work — to another employee or position, or to leave it vacant — and only then proposes the deletion.
- Read-only sessions cannot write. Users without write permission cannot make changes through the AI at all; the assistant declines change requests and suggests contacting an organization admin.
Content-level access
Content-level permissions apply through the AI client just as they do in the app. Folders are visible to every active member, but individual documents inside a folder can be restricted. For example, an Org Admin who has not been granted access to a specific document cannot read that document through the AI client. See Permissions and roles for the underlying model.
Some content tools depend on your content access role rather than your admin role. The document-access tool, for instance, is available to members with Editor, Global Task Editor, or Global Editor access and acts only on documents they can edit. A member without an admin role can therefore use it, while a Viewer cannot.