> For the complete documentation index, see [llms.txt](https://docs.kinesis.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kinesis.network/organizations/sharing.md).

# Sharing and visibility

Control which organization members can see and use projects, apps and grids.

Sharing gives members of the same organization access to a private project, app or grid. Invite a new colleague into the organization first, or invite them from the resource's Share dialog so they are added when they join.

## Private or everyone

| Visibility                        | Who can access it                                        |
| --------------------------------- | -------------------------------------------------------- |
| **Private**                       | Organization admins, its creator and members added to it |
| **Everyone at your organization** | All organization members, within their roles             |

Projects are private by default. Choose visibility when creating a project, or change it under the project name as its creator or an admin. Admins choose a grid's visibility in its settings.

Apps follow their project's visibility. You can also add a member to one app without giving them the rest of the project. Access to a project covers its apps.

## Add members directly

Open **Share → People in your organization**, search for members and add them. Access begins immediately; they do not need to accept another invitation.

Admins manage access to every resource. Developers manage access to projects and apps they created. Choose Viewer or Developer access for a project or app; the grant cannot exceed the person's organization role.

Revoking an individual grant does not remove access supplied by another rule. For example, an organization-wide project remains visible to members, and a project grant still grants access to its apps. Change the applicable visibility or project grant if you need to remove that access.

## Share a grid for use

Only organization admins manage grid composition, policies and sharing. A shared grid gives members permission to use its capacity, not to administer it. Developers can deploy apps to accessible grids; Viewers can inspect them.

Grid quotas and fair-share turns count against the person who created the app. Sharing the app does not move its quota usage to the person starting it. See [Grids and shared capacity](/getting-started/running-llms-with-kinesis-network/understanding-grids.md).

## API values and permissions

Organization roles are `admin`, `developer` and `viewer`. Resource-grant payloads retain the wire values `editor` and `viewer`: **`editor` is Developer in the portal**. Do not send `developer` where a resource-grant schema expects `editor`.

`add_grantees` / `POST /sharing/grantees` takes `resourceType`, `resourceId` and a `people` array of `userId` and `role`. Obtain user IDs with `list_members` / `GET /members`. Grids accept `viewer` only; organization role determines whether the member can deploy or only read.

Sharing uses the resource family's admin scope: `projects:admin`, `apps:admin` or `pools:admin`. The person must also meet the creator/admin rule. Invitation `addTo` needs the matching resource admin scope as well as `members:write`.

Use `list_grantees`, `set_grantee_role` and `revoke_access` to inspect or change grants. To give up your own grant, use `leave_shared_resource` with `account:write`. Older invitation operations remain in the reference for handling existing invitations; new colleagues join through organization invitations.

[REST sharing reference](/api/sharing.md) · [MCP sharing reference](/mcp/tools/sharing.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.kinesis.network/organizations/sharing.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.