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

# Vulcan: Access control

## What does it enable?

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

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

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

## Who can create a Vulcan resource?

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

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

A Vulcan resource runs on Compute, so it needs a `Can Use` grant on the Compute it references:

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

The grant can come from either the Compute'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 the Compute gives you `Can Edit` and `Can Manage Access`. Using it in a Vulcan 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 Vulcan resource owner manages access to it
* the Compute owner manages access to the Compute

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 someone else owns, ask its owner (or anyone else holding `Can Manage Access` on it) for the grant first.

## What happens after the Vulcan 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 Vulcan resource:

| Permission          | Lets the grantee                  |
| ------------------- | --------------------------------- |
| `Can Edit`          | Update the Vulcan 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/vulcan-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.