docs: say that a snapshotter can tag environments

administration/authentication/service_accounts.md

@@ -35,7 +35,7 @@ Service accounts have the same role model as users: **Admin**, **Member**, **Sna
 See [Roles in Kosli](/administration/managing_users/roles_in_kosli) for the full permissions matrix. As a starting point:
 
 - **Member** — CI/CD systems that report attestations, manage flows, and create resources.
-- **Snapshotter** — runtime reporters that record environment snapshots and create environments (for example, CLI callers using `--auto-environment`).
+- **Snapshotter** — runtime reporters that record environment snapshots and create and tag environments (for example, CLI callers using `--auto-environment`).
 - **Reader** — read-only systems such as dashboards or query tooling.
 - **Admin** — rarely needed; reserve for automation that manages users, roles, or organization-wide settings (for example, Terraform-driven org bootstrap).
 

administration/managing_users/roles_in_kosli.md

@@ -14,7 +14,7 @@ Roles apply to service accounts the same way they apply to users. Wherever this
 |------|-------------|----------|
 | **Admin** | Full control over the organization | Organization owners, security leads, platform engineering leads |
 | **Member** | Can create and modify resources | Developers, platform engineers, CI/CD systems |
-| **Snapshotter** | Can report snapshots and create environments, and create service accounts in the web UI | Environment and operations teams |
+| **Snapshotter** | Can report snapshots, create and tag environments, and create service accounts in the web UI | Environment and operations teams |
 | **Reader** | Read-only access to view data | Auditors, compliance officers, stakeholders, reporting systems |
 
 ## Permissions Matrix
@@ -46,7 +46,8 @@ Roles apply to service accounts the same way they apply to users. Wherever this
 | Update attestation types | ✅ | ✅ | ❌ | ❌ |
 | Archive attestation types | ✅ | Own only\* | ❌ | ❌ |
 | Manage repos | ✅ | ✅ | ❌ | ❌ |
-| Tag flows, environments, repos, and controls | ✅ | ✅ | ❌ | ❌ |
+| Tag environments | ✅ | ✅ | ✅ | ❌ |
+| Tag flows, repos, and controls | ✅ | ✅ | ❌ | ❌ |
 | Add to and revoke from the allowlist | ✅ | ✅ | ❌ | ❌ |
 | **Attestations & Snapshots** | | | |
 | Report attestations | ✅ | ✅ | ❌ | ❌ |
@@ -67,7 +68,7 @@ Roles apply to service accounts the same way they apply to users. Wherever this
 
 \* Admins can act on any service account or attestation type. Other roles can act only on the ones they created themselves.
 
-† Snapshotters can create and manage service accounts in the web UI only. The API allows a snapshotter no writes beyond reporting environment snapshots and creating environments.
+† Snapshotters can create and manage service accounts in the web UI only. The API allows a snapshotter no writes beyond reporting environment snapshots, creating environments and tagging them.
 
 ‡ Creating an environment that already exists succeeds as long as the request would not change it, so CI pipelines that create the same environment at the same time don't fail. A request that would change an existing environment needs the Member or Admin role.
 
@@ -143,22 +144,23 @@ The following sections provide more details about each Kosli user role, includin
   <Accordion title="Snapshotter" icon="camera">
 
 
-  Snapshotters can create environments, report environment snapshots, and create service accounts in the web UI, but cannot modify other resources, manage users, configure integrations, or change organization-wide settings.
+  Snapshotters can create and tag environments, report environment snapshots, and create service accounts in the web UI, but cannot modify other resources, manage users, configure integrations, or change organization-wide settings.
 
   ### Permissions
 
   Snapshotters can:
 
   - **Service Accounts**: In the web UI only, create service accounts and manage the ones they created and those accounts' API keys. The API does not allow a snapshotter to do this.
   - **Environments**: Create new environments (needed so CLI flows like `--auto-environment` work with a snapshotter token). Creating an environment that already exists succeeds as long as the request would not change it.
+  - **Tags**: Set and remove tags on environments (`kosli tag environment`).
   - **Snapshots**: Report environment snapshots.
   - **View Data**: Access trails, artifacts, attestations, and snapshots.
   - **Query Information**: Search and filter data across flows and environments.
   - **Generate Reports**: Export and analyze compliance data.
   - **View Configurations**: See flow definitions, policies, attestation types, and actions (but cannot modify them).
 
   Snapshotters cannot:
-  - Change an existing environment, whether through the update endpoints or by re-creating it with different settings.
+  - Change an existing environment other than its tags, whether through the update endpoints or by re-creating it with different settings.
   - Archive environments.
   - Create, update, or delete flows, policies, attestation types, or other resources.
   - Report attestations.

implementation_guide/phase_1/roles_and_responsibilities/overview.md

@@ -73,7 +73,7 @@ The RACI matrix above describes responsibilities during Kosli implementation. To
 Kosli user roles control what actions someone can perform in the Kosli system:
 - **Admin**: Full control, including user management and organization settings
 - **Member**: Can create and modify resources, manage service accounts, and configure integrations
-- **Snapshotter**: Can report environment snapshots, create environments, and manage service accounts, with read-only access to other resources
+- **Snapshotter**: Can report environment snapshots, create and tag environments, and manage service accounts, with read-only access to other resources
 - **Reader**: Read-only access to view data and compliance status
 
 For guidance on which Kosli user role to assign based on organizational responsibilities, see [Roles in Kosli](/administration/managing_users/roles_in_kosli) and [Mapping users to roles](/administration/managing_users/mapping_users_to_roles).