Label-scoped artifact grants

Enterprise accounts can assign a reviewer or agent access to transcripts and documents with specific artifact labels. The feature is off by default. It requires a core version that supports artifact read predicates and request guards. An older installation shows the control but refuses enablement and reviewer assignment until the core submodule is updated.

In Settings > Users > Artifact read grants, enable the account setting, select a user, managed agent or API key by its ID, enter the exact site label, and select Transcripts and/or Documents. Grant management requires manage_users, manage_agents, and search_session_content; changing the account setting requires manage_account and search_session_content. No account-wide grant or public MCP management tool is provided.

Assign the Works council reviewer system role (works_council_reviewer) through Manage roles. A reviewer can read the session list's metadata and matching artifacts. The role is a restrictive ceiling, including when inherited from a team or combined with another role. It does not permit writes, agent control, model inference, MCP invocation, session content search, timelines, or evidence exports. Existing API keys and OAuth credentials remain subject to this ceiling. Session metadata may describe other sites; artifact content, search results, counts and facets are label-filtered.

Grant shape and matching

The account metadata stores explicit subjects under artifact_grants, for example:

{
  "artifact_grants_enabled": true,
  "artifact_grants": {
    "users": {
      "00000000-0000-0000-0000-000000000001": {
        "artifact_read_scope": {
          "labels": {"site": ["north"]},
          "kinds": ["transcript", "document"]
        }
      }
    }
  }
}

Labels use exact, case-sensitive string matching. Different label keys must all match; any permitted value of each key may match. Kinds also must match. Applicable user, key and managed-agent scopes intersect. Empty or malformed scopes deny all. Reviewer accounts without an assigned scope see no artifacts. There is no wildcard, label inheritance, or cross-account hierarchy access.

Managed-agent and API-key assignments also write tool_grants["artifact_search.account_scope"] in the existing subject governance store. This allows account-scope artifact search, narrowed by the assigned predicate. Ordinary subjects without artifact grants keep their existing behavior. A grant never changes account membership or bypasses session-bound credentials.

Revocation and audit

Revoke stores artifact_read_scope: null and refuses account-scope tool search for the subject. The explicit deny is retained so ambient access or another grant cannot restore visibility. The next read after the transaction commits uses the new database state, without a governance cache. Reads already in flight may finish; downloaded bytes cannot be recalled.

Revocation remains available while the feature is disabled or core has been rolled back. A revoked assignment stays denied when the feature is re-enabled.

Disabling the account setting hides artifacts from assigned subjects and reviewers. Re-enabling restores unrevoked assignments. Unrelated governance writes preserve the grant bucket and the known account-scope tool grant.

Grant creation, revocation and setting changes write audit rows in the same transaction as the change. Each returned artifact is audited with its ID, labels, kind and authenticated subject. An audit failure prevents disclosure. Hierarchy-aware reads are deferred; all reads remain within one account.

The core policy resolver uses None only for an unassigned subject. An empty list denies all; assigned scopes intersect and malformed scopes deny all. Artifact text in session-search results follows the same label predicate.

Administrators can remove reviewer role assignments even while the feature is disabled or core has been rolled back. New assignments still require enablement.

A direct account owner who also holds the reviewer role can recover with DELETE /api/v1/users/me/reviewer-role using their existing authenticated session. This removes only their direct reviewer assignment and their own memberships in reviewer teams; it leaves other users, team roles and unrelated memberships unchanged. Recovery is audited and works while the feature is disabled or core has been rolled back. Non-owner reviewers cannot use this path.