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

# Scopes

> The access your application can be granted.

Every endpoint requires a scope. Scopes are granted to your application in the Developer Console; a
request without sufficient access is rejected with `403 scope_required`.

## Access levels

In the Developer Console you grant an application one of three access levels, which map to two
scopes:

| Access level    | Scope(s) granted         | Grants                                                                   |
| --------------- | ------------------------ | ------------------------------------------------------------------------ |
| **Read**        | `all:read`               | Read access to every resource.                                           |
| **Write**       | `all:write`              | Write access to every resource (**write-only** — does not include read). |
| **Full access** | `all:read` + `all:write` | Read and write access to every resource.                                 |

`all:read` satisfies any read (`GET`) endpoint and `all:write` satisfies any write (`PATCH`)
endpoint, evaluated at request time.

## Forward-covering

The scopes are **forward-covering**. Because `all:read` satisfies any read check and `all:write`
satisfies any write check at request time, an application automatically gains access to **new
resource types as their endpoints ship** — with no re-grant and no re-consent. Grant an access level
once and it keeps covering the API as it grows.

<Note>
  Materially sensitive resource classes (for example audit logs, connection credentials, or
  vendors) may be gated behind an explicit scope when they ship, even for applications holding
  `all:read` / `all:write`.
</Note>

<Note>
  **Employee PII under read access.** EMPLOYEE-category assets returned by the inventory endpoints
  include the employee's `email` address (personally identifiable information). This PII is surfaced
  under read access (`all:read`) — it is **not** gated behind a separate scope. Grant read access
  only to applications you intend to give access to employee email addresses.
</Note>

<Note>
  Finer-grained, per-resource scopes (for example read-only access to just the inventory) are
  planned for a future release. In v1, access is read and/or write across all resources.
</Note>