# Access and permissions

Understand organisation and project access, publication authority and permission refusals.

Source: https://docs.openeng.io/concepts/access/

Your session has one active organisation. Its type catalogue gives projects a shared vocabulary; project grants control the engineering data you can work with. Select the intended organisation and project before acting in the workspace or attaching the CLI.

## Where changes live

| Work | Scope and approval |
|---|---|
| Read or edit objects and relationships | Project access and the selected engineering branch; protected work has additional rules |
| Create branches and review proposals | Project capabilities, including separate authority to merge |
| Publish types and views | Organisation catalogue change set; permission to publish is separate from object editing |
| Create projects and manage membership | Administration capabilities in the relevant scope |
| Create service identities and issue credentials | Organisation administration; the identity needs its own grants to read or write data |

Roles bundle capabilities. The available roles and their permissions come from the deployment; a familiar role label alone is not a guarantee that a particular operation is allowed. An organisation-level membership reaches its projects; a project-level membership confines that grant to that project.

Reading a project does not imply permission to edit, publish types, administer members or merge. A relationship to another project's object does not grant access to that object's properties.

## Manage membership in the workspace

An administrator opens **Admin** and chooses **Organisation members**. Under **Grant a role**, choose the **Member identity**, select the **Scope** and **Role**, then choose **Grant role**. Use project scope when the grant should apply to one project. The table shows the current scope and role for each membership.

To change an existing membership, select its role in the row and choose **Change role**. **Revoke** removes that membership. The platform checks your authority to grant or change the role; administration does not let you grant a role above your own authority.

The current picker only lists identities already represented in the organisation's member list. Use the Administration SDK or CLI `grantMembership` operation for an initial grant to another existing platform identity, including a new service identity. Membership grants are separate from identity creation, email invitations and public sign-up.

## Understand unavailable controls and refusals

Check the active organisation, project and branch first. A control may be absent because your identity lacks the operation's authority or that action is not available for the current state. A displayed control can still produce a refusal when permissions or data have changed.

Preserve your draft, read the reason, and ask the instance administrator for the capability required by the operation. Do not use another person's credential to bypass a refusal. If a write's outcome is uncertain, inspect or recover it before repeating it.

## Agents and integrations

The in-product agents act with delegated authority from the signed-in person. Plan approval narrows what a run may do; it does not add permissions the person lacks. The ontology agent drafts and validates; you publish its change set. External coding agents using your CLI or SDK session can call operations that your identity may perform, including publication, so give them explicit approval boundaries.

A service identity acts as a program with its own grants. It does not impersonate each user of an external app. See the experimental [external app guide](https://docs.openeng.io/developers/external-apps.md) for setup and the current per-user sign-in limitation.