> For the complete documentation index, see [llms.txt](https://docs.zata.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zata.ai/subusers/roles.md).

# Access Types & Bucket Permissions

A subuser's access is controlled at two levels: the **Access Type** chosen when the subuser is created, and the **bucket access rules** you grant afterward.

### Access Type

Chosen once, when the subuser is created (see [Create a Subuser](/subusers/create-a-subuser.md)):

* **Programmatic access only** — API/CLI access via access keys only. No dashboard login, no email or invitation required.
* **Programmatic + Dashboard access** — Access keys plus a login to the Zata.ai web dashboard. Requires an email address; the subuser must accept an emailed invitation and set their own password before the dashboard login (and their access keys) become usable. A programmatic-only subuser can be upgraded to dashboard access later from their detail page.

Access Type does not by itself grant access to any bucket — it only controls *how* the subuser can connect (keys vs. dashboard login).

### Bucket Access Rules (permissions)

Bucket-level permissions are assigned per subuser, per bucket, using **Access Rules** — see [Create a Subuser](/subusers/create-a-subuser.md) for how to add one. A rule can optionally be scoped to a single folder (prefix) inside the bucket instead of the whole bucket.

| Permission        | Description                                                                              | Typical use                                                                          |
| ----------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| **View Only**     | List and download objects only. No changes can be made.                                  | Read-only access, e.g. for auditors or backup verification                           |
| **Upload Only**   | Create and upload new objects. Cannot list, download, or delete existing objects.        | Write-only intake, e.g. an ingest service that drops files but never reads them back |
| **View & Upload** | List, download, and upload objects. Cannot delete.                                       | Most day-to-day collaborators                                                        |
| **Full Access**   | Complete control over the bucket's objects, including delete, tags, and versioning info. | Trusted admins of that bucket                                                        |

A few actions (bucket ACL changes, `PutBucketVersioning`, and tag writes) are always withheld from subusers regardless of the permission chosen, and bucket-wide settings like versioning/tagging status are not grantable when a rule is scoped to a folder rather than the whole bucket.

Each access rule can be edited, temporarily suspended (without deleting it), or revoked at any time from the subuser's bucket page — see [Create a Subuser](/subusers/create-a-subuser.md).

Steps to create a subuser and assign access: [Create a Subuser](/subusers/create-a-subuser.md)