> 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/depot-access-control.md).

# Depot: Access control

## What does it enable?

A Depot 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 Depot, you become its owner and automatically receive:

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

A **Tenant Admin** holds that same authority over every Depot 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 Depot. Someone with `Can Manage Access` (the owner, or a Tenant Admin) has to grant it.
{% endhint %}

## Who can create a Depot?

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

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

A Depot connects to a data source using a Secret for credentials, so that Secret needs its own `Can Use` grant:

| Dependency | Permission needed |
| ---------- | ----------------- |
| Secret     | `Can Use`         |

The grant can come from either the Secret'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="warning" %}
A Depot that connects to a production data source often carries or links to credentials with real access to that system. Treat its creation the same way you would treat the underlying Secret: reserve it for the Tenant Admin or a designated Data Admin, and grant `Can Use Depot` to developers who only need to read from or write to it.
{% endhint %}

{% hint style="info" %}
Owning a resource does not include `Can Use` on it. Creating the Secret gives you `Can Edit` and `Can Manage Access`. Using it in a Depot 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 Depot owner manages who can reference it, and its linked Secret, in a Data Product workload
* the Secret owner manages access to the Secret
* a Tenant Admin can manage access to any Depot or Secret in the Tenant, even one they did not create

If you need to reference a Depot someone else owns, ask its owner (or anyone else holding `Can Manage Access` on it) for `Can Use`.

## What happens after the Depot exists?

Typical grants on an existing Depot:

| Permission          | Lets the grantee                                                      |
| ------------------- | --------------------------------------------------------------------- |
| `Can Use`           | Reference the Depot and its linked Secrets in a Data Product workload |
| `Can Edit`          | Update the Depot                                                      |
| `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/depot-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.