> ## Documentation Index
> Fetch the complete documentation index at: https://docs.neuro-tech.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Manage users, roles, and privileges

> Apply least-privilege access control to administrators, applications, and MCP clients

Neuron authorization is privilege-based. A **role** collects privileges; a user or XMPP account receives the union of privileges from its assigned roles.

## Account types

| Account             | Used for                                                        |
| ------------------- | --------------------------------------------------------------- |
| Administrative user | Browser administration and protected HTTP resources             |
| XMPP account        | Federated messaging, service identities, and clients            |
| OAuth client        | Standards-based authorization to HTTP resources and MCP servers |
| Agent API account   | Application-level Agent API sessions and domain services        |

Do not assume these account types are interchangeable. A deployment can map an OAuth registration to an XMPP account internally, but access is still determined by the roles and privileges assigned to that identity.

## Create a least-privilege role

1. Open **Administration → Users and Roles → Roles**.
2. Create a role named for the job, not for a person, such as `McpFileReader` or `SupportEventViewer`.
3. Add only the privileges required by that job.
4. Assign the role to a test account.
5. verify both an allowed action and a denied action.

Privilege names are hierarchical. Granting a broad parent pattern can include future child privileges, so prefer explicit leaves for machine identities.

## OAuth scopes and privileges

OAuth scopes are translated to Neuron privileges with the prefix `OAUTH.Scope.`; colons in a scope become periods. For example, the MCP scope root `MCP:Files` maps into the `OAUTH.Scope.MCP.Files` privilege hierarchy.

Dynamic OAuth clients and XMPP-backed OAuth clients have no useful privileges by default. Registration establishes identity, not authorization.

## Separate human and machine access

* Give each integration its own account or OAuth client.
* Never share the main administrator credential with a service.
* Rotate a compromised client without affecting unrelated applications.
* Use short-lived bearer tokens and protect refresh tokens.
* Disable an account before deleting it when investigating an incident.
* Log actor, object, facility, module, and event ID for privileged automation.

## Recover administrative access

If all administrator access is lost, stop and identify the active database and program-data folder before editing anything. Recovery procedures are storage-provider and build specific. Make a backup first, then use the recovery utility or documented database procedure shipped with the same build. Do not create a second fresh configuration over the existing data directory; it can replace keys needed to decrypt the database.

## Audit checklist

* Every account has an owner and purpose.
* Machine accounts use narrowly scoped roles.
* Former staff and retired services are disabled.
* OAuth redirect URIs are exact and still controlled.
* Privilege changes produce auditable events.
* Administrative pages are also restricted at the network/WAF layer.