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

# Secret: Access control

## What does it enable?

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

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

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

## Who can create a Secret?

A user with the **Tenant Admin**, **Data Admin**, or **Data Developer** Tenant role can create a Secret. It has no other resources it depends on, so no additional permissions are required to create one.

{% hint style="warning" %}
A Secret that holds production credentials (for Snowflake, Postgres, Databricks, and similar systems) should be created only by someone authorized to handle those credentials, typically the Tenant Admin or a designated Data Admin. Grant `Can Use Secret` to developers who need to authenticate through it, rather than letting them create it themselves.
{% endhint %}

{% hint style="info" %}
Owning a Secret does not include `Can Use` on it. Creating one gives you `Can Edit` and `Can Manage Access`. Referencing it in a Data Product workload 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: nothing about creating a Secret shares it with anyone else, including yourself, until a `Can Use` grant is made.

That means:

* the Secret owner manages who can reference it, and authenticate through it, in a Data Product workload
* a Tenant Admin can manage access to any Secret in the Tenant, even one they did not create

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

## What happens after the Secret exists?

Typical grants on an existing Secret:

| Permission          | Lets the grantee                                                                                                |
| ------------------- | --------------------------------------------------------------------------------------------------------------- |
| `Can Use`           | Reference the Secret in a Data Product workload to authenticate to the external system it holds credentials for |
| `Can Edit`          | Update the Secret                                                                                               |
| `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/secret-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.