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

# Access governance

> Roles, permissions, and the four-eyes controls built into Sengol.

Sengol ships twelve role templates. Each grants a fixed set of permissions.
Map your IdP groups to them, or assign them to local users.

## Roles

| Role | For | Permissions |
| - | - | - |
| `admin` | Platform administrators | everything except `keys:admin` |
| `access-admin` | Identity team | `users:admin` only. Cannot read evidence, so Console pages stay empty. |
| `developer` | Agent builders | `audit:write`, `audit:read`, `intake:submit`, `dataset_rows:write`, `dataset_rows:read`, `guard:write`, `guard:replay` |
| `member` | Standard users, human reviewers | `audit:write`, `audit:read`, `intake:submit` |
| `cro` | Risk and compliance leads | `audit:read`, `reports:generate`, `controlbook:write`, `sod:override`, `judge:challenge`, `audit:erase`, `authority:manage`, `legal_hold:manage`, `retention:approve`, `regression:review`, `sod:approve`, `intake:approve`, `review:configure` |
| `approver` | Second approver for four-eyes steps | `audit:read`, `reports:generate`, `agents:admin`, `sod:override`, `retention:approve`, `erasure:approve`, `regression:review`, `sod:approve`, `intake:approve`, `review:publish`, `guard:approve`, `guard:replay` |
| `validator` | Independent model validation | `audit:read`, `reports:generate`, `judge:challenge`, `regression:review`, `sod:approve` |
| `auditor` | Internal or external audit | `audit:read` |
| `viewer` | Read-only stakeholders | `audit:read` |
| `gateway` | A gateway service, not a person | `gateway:mint`, `audit:write` |
| `eval-worker` | The eval worker for public jobs, not a person | `eval-queue:work`, `audit:write`, `audit:read` |
| `online-eval-worker` | The online-scoring worker, not a person | `eval-queue:work`, `eval-queue:online`, `audit:write` |

> [!WARNING]
>
> `approver` is powerful despite its name. `agents:admin` lets it reveal
> captured raw traces, and `sod:override` lets it authorize same-person
> steps where policy allows. It **cannot** decide human-review items: that
> needs `audit:write`, held by `member`, `developer` and `admin`.

List the templates, with descriptions, as an admin:

```bash theme={null}
ADMIN_JWT=$(curl -s -X POST "$SENGOL_API_URL/v1/auth/token" \
  -H "Content-Type: application/json" \
  -d "{\"grant_type\":\"console_admin\",\"secret\":\"$SENGOL_CONSOLE_ADMIN_SECRET\"}" \
  | python -c 'import sys, json; print(json.load(sys.stdin)["access_token"])')

curl -s "$SENGOL_API_URL/v1/roles" -H "Authorization: Bearer $ADMIN_JWT" \
  | python -c 'import sys, json; [print(r["role_id"], "-", ", ".join(r["permissions"])) for r in json.load(sys.stdin)]'
```

You can also create organization roles. A caller can never grant a
permission it does not hold itself.

## Four-eyes controls

Several actions are four-eyes controls. Erasure and governed transitions always need
two different people. An intake needs two only when your organization sets it:

| Action | Who proposes | Who approves |
| - | - | - |
| Register a new agent (an **intake**), two people only when configured | `intake:submit`: developer, member, admin | `intake:approve`: approver, cro, admin. One approver is enough until an operator sets more per risk tier. |
| Erase a data subject's content | `audit:erase`: cro, admin | `erasure:approve`: approver, admin |
| Governed lifecycle transitions (separation of duties) | the actor | `sod:approve` ballots: approver, cro, validator, admin |
| Approve a guard configuration version | `guard:write`: developer, admin | `guard:approve`: approver, admin. Never the author or proposer of that version. |

An agent must have an approved intake before it can be registered. Until
then, the **Agents** page stays empty even while the agent writes evidence:

![Agents page reading No agents to show, with a Submit an intake link](https://mintcdn.com/sengol/WAzD6pTFOjHwDiMz/images/console-agents.png?fit=max\&auto=format\&n=WAzD6pTFOjHwDiMz\&q=85\&s=e1b6c00d7ddadd0944a0f72b4fd4e3e1)

Agents lists the registry, not evidence. Unregistered agents do not appear.

A developer submits an intake at **Govern → Intakes → New**. An approver
approves it from the intake's page. Out of the box one approver is enough, and
that can be the person who submitted it. An operator can require more people
or a different person per risk tier ([Set who approves
intakes](https://docs.sengol.io/journeys/platform-operator.md#7-set-who-approves-intakes)). The fields
are described in the [AI developer journey](https://docs.sengol.io/journeys/ai-developer.md#7-register-the-agent):

![New intake form with agent id, use case, owner, risk tier and policies](https://mintcdn.com/sengol/WAzD6pTFOjHwDiMz/images/console-intake-new.png?fit=max\&auto=format\&n=WAzD6pTFOjHwDiMz\&q=85\&s=dd7b4c5ed0db88c724b4198dd5690f26)

A new intake. The agent id stays reserved while the intake is submitted and after it is approved or rejected. Only a withdrawn or expired intake releases it.

## Interactive sign-in

Certifying an agent, promoting a judge, activating an obligation, and
confirming, revising or approving an agent intake need an **interactive**
sign-in: SSO, a password login, or `sengol login --device` approved in the
Console. An `sk_` API token or a CI credential is refused.

To require MFA for the most sensitive steps, set
`SENGOL_SOD_REQUIRE_STEP_UP=true`. It applies to objects at the `CRITICAL`
risk tier. For MFA everywhere, enforce it at your IdP.

## What is and is not signed evidence

Signed records cover evaluations, certifications, gold scores and erasure
tombstones. **Account administration is not signed**: creating users,
assigning roles, SCIM changes and break-glass sign-ins leave logs, not
records an auditor can verify offline. Keep your IdP's own audit log for
those.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.