> For the complete documentation index, see [llms.txt](https://docs.mithril.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mithril.ai/account-and-billing/access-management.md).

# Access management

Mithril employs a straightforward structure for permissions to streamline management and establish clear boundaries of authority and access. While Mithril has a default nomenclature for entities and relationships, we also allow the flexibility for organizations to port existing IAM structures from AWS or GCP. 

This article details the structure of entities within Mithril.

## Entities in Mithril

There are four core entity types in Mithril:

1. Organizations
2. Projects
3. Users
4. Resources (instances, storage, keys, etc)

### Relationships between entities

* **Users** belong to an **organization**
* **Projects** belong to an **organization**
* **Compute & storage resources** belong to a single **project**
* **Users** have access to selected **projects** within their **organization**. 
* Users with access to a **project** have access to all **resources** within that **project**.

## Managing users

Administrators can new users to their organization or deactivate existing users. An user can be either an Administrator or a Member:

1. Administrators
   * Can invite new members to the organization.
   * Can modify any team member's role in the organization.
   * Have the authority to view and modify billing details, settle invoices, and initiate new projects.
   * Can add or remove team members from projects.
   * Have access to all projects within the organization.
2. Members
   * Member permissions depend on the projects they are granted access to by an administrator.
   * Within the projects they're affiliated with, members possess complete operational capabilities, such as creating, starting, stopping, and terminating instances.

### User role considerations

By design, granular access control over specific resources *within* a project is not possible. In the case that certain users should not have access to certain resources, privileged resources should be split into separate projects.

### Deactivating a user considerations

While deactivating a user is easy in Settings, note that your deactivated users may still have access to instances if they retain the SSH key. We recommend rolling SSH keys to ensure best practices with deactivated users.

## Managing projects

Projects are a workspace within an organization for users to create and access compute or storage resources. Compute and storage within a project can only be accessed if your user has access to it. Most organizations use projects to:

* Organize resources by team (e.g., Product team, Infra team)
* Organize resources by cost bucket / code (e.g., R\&D vs COGS)
* Separate production, staging, and dev environments
* Sandbox interns or contractors to limit access to sensitive environments

Projects can be renamed in the Settings modal.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.mithril.ai/account-and-billing/access-management.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.