--- title: "Who Can Run What: AI Workspace Permissions" url: https://www.insulin.dev/blog/role-based-access-for-ai-workspaces/ canonical: https://www.insulin.dev/blog/role-based-access-for-ai-workspaces/ type: Blog description: "Sharing an AI agent across a company raises a question a personal tool never does: who can change it. How roles and install scopes fit together." --- # Who Can Run What: AI Workspace Permissions > Canonical HTML version: https://www.insulin.dev/blog/role-based-access-for-ai-workspaces/ 1. [Home](/) 2. / 3. [Blog](/blog/) 4. / 5. Who Can Run What: AI Workspace Permissions # Who Can Run What: AI Workspace Permissions Sharing an AI agent across a company raises a question a personal tool never does: who can change it. How roles and install scopes fit together. ![Chengjun Yuan](/leadership/chengjun.jpeg) Chengjun Yuan Co-founder & CTO · Aug 11, 2026 ![Who Can Run What: AI Workspace Permissions](/images/blog/role-based-access-for-ai-workspaces/hero.png) Explore AI Summary [![](/logos/company/openai.svg)](https://chat.openai.com/?q=Read%20and%20summarize%20https%3A%2F%2Fwww.insulin.dev%2Fblog%2Frole-based-access-for-ai-workspaces%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20Workspace%2C%20Security. "Summarize with ChatGPT")[![](/logos/company/anthropic.svg) ](https://claude.ai/new?q=Read%20and%20summarize%20https%3A%2F%2Fwww.insulin.dev%2Fblog%2Frole-based-access-for-ai-workspaces%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20Workspace%2C%20Security. "Summarize with Claude")[![](/logos/company/gemini.svg)](https://www.google.com/search?udm=50&aep=11&q=Read%20and%20summarize%20https%3A%2F%2Fwww.insulin.dev%2Fblog%2Frole-based-access-for-ai-workspaces%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20Workspace%2C%20Security. "Summarize with Gemini")[](https://www.perplexity.ai/search/new?q=Read%20and%20summarize%20https%3A%2F%2Fwww.insulin.dev%2Fblog%2Frole-based-access-for-ai-workspaces%2F%2C%20then%20cite%20the%20source.%20Focus%20on%20what%20it%20says%20about%20Workspace%2C%20Security. "Summarize with Perplexity") Table of Contents - [The five roles](#the-five-roles) - [Default plus exception](#default-plus-exception) - [Install scope is the other half](#install-scope-is-the-other-half) - [What roles do not cover](#what-roles-do-not-cover) - [Frequently asked questions](#frequently-asked-questions) - [Takeaways](#takeaways) _Role-based access in Insulin controls who may view, run, edit, or own a shared agent or app. It answers a question personal AI tools never raise: when something is used by the whole company, who is allowed to change it?_ * * * A personal AI assistant has no permission model worth discussing. You built it, you use it, and if it is wrong you fix it. The moment it is shared, three questions appear at once. Who can use it? Who can change it? And when it produces something wrong six weeks from now, who is responsible for it? The third question is the one organisations get wrong, because it is not a technical question and it does not get asked until the answer is needed. Roles are how you answer all three in advance. * * * ## **The five roles** Insulin’s organization-level Custom Apps use a five-role ladder, applied org-wide by default and overridable per person: Role Can do **Viewer** View only **User** Run it **Editor** Edit and run **Admin** Edit, run, and manage sharing **Owner** Full control, including transfer Shared agents use the same idea with three levels — admin, editor, and user — granted to named people or to everyone in the organization at once. The distinction that does the most work is **User versus Editor**: running something and changing it are different privileges, and conflating them is the most common mistake. Most people need to run an app. Very few need to modify the thing everyone else depends on. When those are the same permission, the app drifts — each person adjusts it slightly for their own use, and within a quarter nobody is sure what the shared version does. **Owner** matters for a duller reason: transfer. An app or agent whose owner has changed teams is an asset with no maintainer, and the person who needs it changed discovers this at the worst moment. Assign ownership to somebody who will still care in six months, and move it when they move. * * * ## **Default plus exception** The pattern Insulin uses — one org-wide default role, overridden per person — is worth adopting deliberately rather than accepting by inertia. **Set the default at the level most people need.** For most shared apps that is Viewer or User. It is the level where the app is useful and nothing can be broken. **Grant editing to named people, not to groups.** “The finance team can edit” sounds reasonable and means nobody in particular is responsible. Two or three named editors is usually right, and the fact that they are named is the point. **Remember that the two grants combine.** Share with the whole organization and a member gets the default role; assign that same person a role directly and their effective access is the higher of the two. Granting an individual less than the org default does not reduce anything. **Revisit after the first month.** Rollouts over-grant, because it is faster than deciding. Once real usage exists you can see who actually edited anything, and the answer is nearly always fewer people than were granted the right. * * * ## **Install scope is the other half** Roles decide what someone may do with a shared component. **Install scope** decides whether it is shared at all — and the two work together. An Insulin agent or skill installs at one of two scopes: for a single user, or for the whole organization. That is not merely a distribution setting; it is an evaluation mechanism. Install for yourself first. Use it on real work for a week, on real questions, with real consequences if it is wrong. Most components do not survive that week, and finding out privately costs nothing but your own time. The ones that do survive have earned an org-wide install, and by then you know what to say about them when people ask what it is for. Rolling out first and evaluating later inverts this, and the cost is not just a bad tool — it is that the next rollout is met with scepticism regardless of quality. The order is covered further in [build or install](/blog/reusable-ai-agents-build-or-install/) and in [scoping agents](/blog/one-ai-assistant-or-many-specialists/). * * * ## **What roles do not cover** Two boundaries worth keeping distinct in your head, because they look similar and fail differently. **Roles govern people. Integration scope governs the agent.** A user with permission to run an agent gets whatever that agent can reach — the role does not narrow it. If a person should not be able to pull data from a system, the control is which integrations the agent has, not which role the person holds. **Roles govern change. Approval governs action.** Editor rights decide who can rewrite an agent’s instructions. [Approval workflows](/blog/human-approval-for-ai-agents/) decide whether a given run does anything. A read-only user still triggers real tool calls when they run an agent — which is exactly why the approval gate exists separately. * * * ## **Frequently asked questions** **What roles does an Insulin Custom App support?** Viewer, User, Editor, Admin and Owner. The role is applied organization-wide as a default and can be overridden for individual people. **How are shared agents controlled?** An organization-level agent supports admin, editor and user roles, granted either to named people or to everyone in the organization. A user-level agent stays private. **What default role should we set?** Usually Viewer or User — the level where the thing is useful and nothing can be broken. Grant editing to two or three named people rather than to a group. **Do roles limit what data an agent can reach?** No. Roles govern what people may do with the agent; the agent’s own integration scope governs what data it can reach. Those are separate controls that fail differently. **Should we install a component for everyone straight away?** No. Install it for yourself, use it on real work for a week, and roll it out organization-wide only if it earns its place. Most components do not survive that week. * * * ## **Takeaways** - Running and editing are different privileges. Conflating them is how a shared app drifts. - Set the org default where most people need it, then name two or three editors. - Ownership matters for transfer — an unowned app is an asset with no maintainer. - Install for yourself, prove it for a week, then install org-wide. The reverse costs credibility. - Roles govern people; integration scope governs the agent; approval governs the action. Keep all three. Insulin shares agents and apps with role-based access, and installs components per user or organization-wide. [Explore Insulin agents](/agents/), [see Custom Apps](/custom-apps/), or [get a demo](/schedule-demo/). ## Sources Primary sources for the platform rules cited above. Last verified August 14, 2026. Cloud providers change fees, eligibility, and program terms without notice — check the source before relying on a figure. - [Suger Insulin docs: Custom Apps](https://doc.suger.io/insulin/custom-apps/) — Owner, Admin, Editor, User and Viewer roles and what each may do; sharing with the entire organization sets a default role for every member, sharing with specific users assigns a role directly, and a member's effective access is the higher of the two. - [Suger Insulin docs: Agents](https://doc.suger.io/insulin/agents/) — Personal versus Organization ownership, and the ADMIN, EDITOR and USER roles on a shared agent, with org-level integration edits requiring admin access. ### Stay Updated Get the latest Cloud GTM insights, product updates, and marketplace strategies delivered to your inbox.