Skip to content

Access boundaries

Context Control Center (CCC) applies separate access checks in different parts of the UI and selection pipeline. Site builders and integrators should not assume that one CCC permission grants access to unrelated entities or admin routes.

This page documents the security model enforced in code. It complements the authoring trust model in Configuration — Permissions.

Three independent checks

Context item view access

Controls whether a user can view a context item in the admin UI, in revision history, and in AI selection or context tools for that user.

Published items are viewable when the account has View AI Context Items or Access published AI Context. Unpublished items require View any unpublished AI Context Item, or ownership plus View AI Context Items.

Selection and function-call plugins enforce the same view access for the current user. Unpublished or inaccessible items are excluded from injected context and from tool responses.

Usage record access

Controls whether a user can open the usage listing and individual usage records at /admin/config/ai/context/usage.

Requires View AI Context Usage and (for the listing) usage tracking to be enabled in settings. Usage entities have their own access handler; holding this permission does not bypass context item or target-entity checks on linked data (see below).

Referenced target-entity access

When a usage record stores a target entity (for example the node an agent was editing), CCC checks that entity's normal Drupal view access before linking to it or showing its label.

If the user cannot view the target entity, the usage UI shows a type-and-ID fallback with (no access) instead of a link.

The internal display helpers AiContextItem::getEntityItemData() and buildEntityItemRenderArray() use the same view-access check. Inaccessible entities are omitted from labels and links (not shown as (no access)). buildEntityItemRenderArray() still bubbles each referenced entity and its view-access result so the display updates if access changes. getEntityItems() stays unfiltered; it is for matching and storage, not display.

Usage permission does not grant item access

View AI Context Usage allows observability pages only. It does not grant permission to view the associated context item, its content, or referenced target entities.

On usage listing and detail pages, CCC redacts inaccessible references:

  • Context items the user cannot view show Context item {id} (no access) instead of a label link.
  • The Context item content section on a usage record is omitted when view access is denied.
  • Target entities the user cannot view show {type}:{id} (no access) or a plain type-and-ID label when the entity cannot be loaded.

Grant View AI Context Items or Access published AI Context (and unpublished permissions when needed) separately for users who must follow links into context items from usage data.

Target entities control applicability, not access

The Target entities field on a context item and the Target Entity scope control when an item is considered relevant (hard filtering and auto-inclusion during selection). They do not grant the current user permission to view those referenced entities in Drupal.

Selection may include a context item because the user is working on a particular node, but that does not expose the node's full content through CCC unless the user already has entity view access elsewhere on the site.

Imported and copied content lifecycle

Content loaded through Content importers is copied into the context item editor. After import:

  • The text lives on the context item entity and follows context item publication and access rules.
  • Source-entity or source-file permissions do not continue to protect that copied text once it is saved on the item.
  • Sanitization protects the editor from unsafe markup; it does not establish semantic safety for AI prompts. See Review imported content.

Treat published context as potentially visible to every user and agent configuration that can select it, regardless of where the text originated.

Authoring trust (prompt influence)

Roles that can create, edit, publish, or administer context items are trusted with prompt-level influence. Published context — especially Global items — can be injected verbatim into AI agent system prompts for other users.

Permissions that confer authoring or administration are marked restrict access: true in ai_context.permissions.yml for that reason.

Receiving published context in AI features is governed separately by Access published AI Context and view permissions, as described above.