> ## Documentation Index
> Fetch the complete documentation index at: https://gleanfeed.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Scopes

> The scope catalog for Glean Feed API keys and OAuth connections, and the read-only default.

Scopes control what a credential can do. Grant the least access an integration needs. Each operation declares the scope it requires, and the API checks it on every request — holding a key or token is never enough on its own.

## The catalog

There are eight scopes. Read scopes let a credential list and fetch; write scopes let it create or change content.

| Scope             | Grants                                                                 |
| ----------------- | ---------------------------------------------------------------------- |
| `feedback:read`   | List and read feedback requests and their comments.                    |
| `feedback:write`  | Create feedback requests and change their stage or moderation status.  |
| `comments:write`  | Post comments and staff replies, and moderate comments.                |
| `changelog:read`  | List and read changelog entries (including drafts) and their comments. |
| `changelog:write` | Create changelog drafts and publish entries.                           |
| `roadmap:read`    | List and read roadmap items.                                           |
| `roadmap:write`   | Create and edit roadmap items, including stage and target delivery.    |
| `workspace:read`  | Read a workspace summary (no personal data).                           |

## Read-only by default

A credential created with no scopes selected gets the read-only set:

```text theme={null}
feedback:read   changelog:read   roadmap:read   workspace:read
```

Write access is always opt-in. There is no separate delete scope; the supported delete operation is governed by its resource's write scope.

## How scopes are enforced

* **API keys** are granted a fixed set of scopes when you create them. To change scopes, create a new key.
* **OAuth connections**, including the CLI and MCP clients, are granted scopes when you approve them on the consent screen. A client can request scopes, but you approve what it actually receives, and the grant is capped by your role in the workspace.
* A request for an operation whose scope the credential lacks returns `403 forbidden`, and nothing is read or written. Missing the read scope for a resource is also `403`, even inside your own workspace.

<Note>
  Scope and workspace are separate checks. A resource in another workspace returns `404` regardless
  of scope, so an ID from another workspace never reveals whether your scopes would have allowed the
  operation.
</Note>

## Roles

Every scope in the catalog is available to any workspace member, including Moderators. Admin and Owner-only concerns — billing, team, domains, and key management — have no scope because they have no API operation. A credential whose creator is not a member of the workspace grants nothing.