Remote Config permissions
A config and a named environment are independent permission roots. Both start private to their human creator unless workspace visibility is requested. Sharing a config does not implicitly share production. A token's platform role is not a substitute for a resource grant.
| Operation | Required access |
|---|---|
| Read or validate a config schema | Config reader |
| Read or evaluate in a named environment | Config reader and environment reader |
| Create a config or environment | Workspace creator |
| Change a value or environment-specific rules | Config editor and environment editor |
| Read history or analytics | Config editor and environment reader |
| Share a config or environment | Its manager |
| Delete a config | Config manager and write access to all environments containing its values/rules |
| Delete a named environment | Environment manager and edit access to all configs containing its values/rules |
The protected base environment allows current tenant members and enabled service
identities to read and write their permitted configs. It does not grant access to
any config. Environment inheritance only follows readable environments; a hidden
parent never silently falls back to base.
Share explicitly
snug access grant --target configs --id feature.dark-mode \
--subject-kind user --subject-id USER --role reader
snug access grant --target config-environments --id production \
--subject-kind group --subject-id OPERATORS --role editorGrant editor on the config as well when the recipient may change its production
value. A reader grant allows reads, not writes or history. Grant manager only when
the recipient should also share the resource. The same commands accept
--expires-at; snug access revoke removes one grant without removing other access
paths. HTTP clients use POST or DELETE /api/v1/access/{target}/{id}/grants.
Workspace custody
Both create commands accept --workspace-id and --visibility private|workspace.
Workspace visibility follows the workspace's current manager, editor and reader
grants. A human's default is the workspace's default visibility; service accounts
must use workspace custody and cannot leave a private resource owned by nobody.
A create-only service account can publish a config and its initial base value atomically. Creation does not confer subsequent read or edit rights. Those come from workspace or explicit grants. The creator remains recorded for attribution; the workspace owns operational access. Disabled credentials and removed/recreated memberships do not retain their previous grants.
Deleting a config or environment also requires permission to remove all of its values and rules. If any affected value or rule is inaccessible or cannot be changed, the deletion fails and nothing is removed. Deleting an environment that other environments inherit from is also rejected.