> For the complete documentation index, see [llms.txt](https://docs.otari.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.otari.ai/guides/organizations-and-access/access-control.md). # Access control Otari separates who runs the deployment, who signs in to the dashboard, the credentials workloads send, and the limits on what they spend. This page explains how those pieces fit together; each one has a page of its own with the steps and the rules. | Concept | What it is | Page | | ------------------------ | ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Organization | The tenant boundary: owns workspaces, members, provider keys and organization-wide settings | [Organizations and workspaces](/guides/organizations-and-access/organizations-and-workspaces.md) | | Workspace | One app's, environment's, team's or customer's resources inside an organization | [Organizations and workspaces](/guides/organizations-and-access/organizations-and-workspaces.md) | | Member | A person's membership of an organization and some of its workspaces, with a role in each | [Members and invitations](/guides/organizations-and-access/members.md) | | User | Who a request's spend is attributed to, and who per-user budgets apply to | [Sign-in and accounts](https://docs.otari.ai/self-hosting/sign-in#users-and-identities) | | Identity | Who signs in to the dashboard | [Sign-in and accounts](https://docs.otari.ai/self-hosting/sign-in) | | API key | A workload credential bound to one user and one workspace | [API keys](/guides/organizations-and-access/api-keys.md) | | Service key and end user | A key whose requests bill the people an application serves | [Track spend per end user](/guides/organizations-and-access/end-users.md) | | Budget | A spend, token or request limit over a period | [Budgets](/guides/organizations-and-access/budgets.md) | | Provider key | The organization's credential for an upstream LLM provider | [Provider keys](/guides/organizations-and-access/provider-keys.md) | | Master key and operators | Authority over the deployment as a whole | [Deployment-wide account administration](https://docs.otari.ai/self-hosting/sign-in#deployment-wide-account-administration) | ## How they relate An organization holds workspaces, and a member belongs to the organization and to the workspaces they were given, with one of four [roles](/guides/organizations-and-access/organizations-and-workspaces.md#roles) in each. A member signs in as an identity, and the user record behind that identity is what their spend is recorded against. Applications never sign in. They send an API key, and the key ties each request to one workspace and one user. The workspace decides which provider keys, aliases, routing policies and tools the request can use; the user, narrowed by the key, decides which models it can reach, and the user's budget is the one it spends. The provider keys Otari calls upstream with belong to the organization, and the application never sees them. Budgets sit over all of it. A per-user budget limits each user on it, and a scoped budget caps an organization, a workspace, a membership or a single API key. A request has to fit every budget that applies. The master key, and an identity granted operator access, act on the whole deployment; organization roles stop at their organization. ## How a request is attributed The API key that authenticates a request determines its workspace. A caller cannot select another workspace with a header, and an inference request on the master key uses the deployment's default workspace. The request's usage is recorded in that workspace and its spend billed to the key's user. A client-provided `user` value never moves spend away from the key's user: by default a request naming another user is refused, and a key set to accept it still bills its own user (see [Mismatched `user` fields](/guides/organizations-and-access/api-keys.md#mismatched-user-fields)). The one exception is a [service key](/guides/organizations-and-access/end-users.md), which bills end users that belong to its own user. A dashboard session authorizes the management API, not inference; see [Dashboard sessions and identity](https://docs.otari.ai/self-hosting/sign-in#dashboard-sessions-and-identity). The generated [OpenAPI specification](https://github.com/mozilla-ai/otari/blob/v0.37.0/docs/public/openapi.json) is the source of truth for endpoint schemas. --- # 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.otari.ai/guides/organizations-and-access/access-control.md?ask=&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.