> For the complete documentation index, see [llms.txt](https://v2.dataos.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v2.dataos.info/operate/v1/access-model/resource-level-permissions/nilus-access-control.md).

# Nilus: Access control

## What does it enable?

A Nilus resource follows the same access model as every other DataOS resource: nothing is shared automatically, and every permission traces back to someone who granted it.

When you create a Nilus resource, you become its owner and automatically receive:

* `Can Edit`: update the Nilus resource
* `Can Manage Access`: grant or revoke access to it for others

A **Tenant Admin** holds that same authority over every Nilus resource in the Tenant, whether or not they created it.

{% hint style="info" %}
Holding a Tenant role does not by itself give you access to a specific Nilus resource. Someone with `Can Manage Access` (the owner, or a Tenant Admin) has to grant it.
{% endhint %}

## Who can create a Nilus resource?

A user with the **Tenant Admin**, **Data Admin**, or **Data Developer** Tenant role can create a Nilus resource, provided they also hold the permissions it depends on.

### What do you need before you can create one?

A Nilus resource runs on Compute and reads or writes through a Depot, and using a Depot does not carry the Secret behind it, so each of these needs its own `Can Use` grant:

| Dependency                      | Permission needed |
| ------------------------------- | ----------------- |
| Compute                         | `Can Use`         |
| Depot                           | `Can Use`         |
| The Secret linked to that Depot | `Can Use`         |

The grant can come from either the resource's owner or anyone who already holds `Can Manage Access` on it, including a Tenant Admin, who can grant the access to themself or others. That grant is audited either way.

{% hint style="info" %}
Owning a resource does not include `Can Use` on it. Creating a Compute, Depot, or Secret gives you `Can Edit` and `Can Manage Access`. Using it in a Nilus resource still requires a `Can Use` grant, which you give yourself with your `Can Manage Access` authority. That self-grant is audited like any other.
{% endhint %}

## What is the common access pattern?

DataOS access is deny by default: owning one resource never extends access to the resources it depends on.

That means:

* the Nilus resource owner manages access to it
* the Compute owner manages access to the Compute
* the Depot owner manages access to the Depot
* the Secret owner manages access to the Secret behind the Depot

Anyone with `Can Manage Access` on a resource can grant access on it, even without being the original creator. Within the Tenant, a Tenant Admin can do the same across all of them.

If you need to use a Compute, Depot, or its underlying Secret owned by someone else, ask its owner (or anyone else holding `Can Manage Access` on it) for the grant first.

## What happens after the Nilus resource exists?

Once created, the owner controls who can work on it. A Tenant Admin can manage access to it too, even without having created it.

Typical grants on an existing Nilus resource:

| Permission          | Lets the grantee                  |
| ------------------- | --------------------------------- |
| `Can Edit`          | Update the Nilus resource         |
| `Can Manage Access` | Grant or revoke access for others |

For the full access model, see [Access control](/operate/v1/access-model.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 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://v2.dataos.info/operate/v1/access-model/resource-level-permissions/nilus-access-control.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.