**Problem/Motivation** The AI subsystem largely assumes tool execution and access checks rely on the active web session (`\Drupal::currentUser()`). For background agents, cron, queue workers (Symfony Messenger), and outside-in entry points (MCP, orchestration APIs), that assumption breaks down: queued work loses the account it was initiated under, cron paths run as anonymous, and helpers read ambient `currentUser()` state. The result is incorrect access checks and incorrect authorship. Attempts to fill the gap with synthetic users or temporary role mutation (e.g. [#3518167](https://git.drupalcode.org/project/ai_agents/-/work_items/3518167)) introduce systemic risks: 1. **Security and privilege ambiguity**: faking roles without a fully loaded, real account bypasses core invariants; a mutation that fails to revert is privilege escalation. 2. **Cache poisoning**: core access results cache against the real evaluated account ([#2628870](https://www.drupal.org/project/drupal/issues/2628870)). 3. **Governance breakdown**: revisions, audit logs, Content Moderation, and Workspaces need a stable, real user entity to record who authored a change. Because LLM agents are non-deterministic, the platform they run on must be hyper-deterministic. Earlier revisions of this issue also tried to define a general identity model (Executor/Initiator/Modality) and a full run-metadata envelope. That scope mixed two different problems and has been split (see "What moved out" below). This issue now owns the narrow, implementable contract that fixes the concrete defects: **a sessionless or deferred AI operation must always know, carry, and enforce the real Drupal account it executes as.** **Proposed resolution** Add a small, serializable executor reference and one shared runner service. Trusted entry points resolve the executor; asynchronous transports carry the reference; the runner loads and validates the account, switches with core `account_switcher`, executes, and restores the previous account in a `finally` block. Executor selection is decided by the trusted boundary, and is bound to how the run originated: | Entry point | Executor | | --- | --- | | Interactive Drupal request | The current authenticated account | | Outside-in request on behalf of a person | The person, resolved server-side from the authenticated credential to their active Drupal account | | Queue/Messenger work created by a person | That person's executor reference, copied into the payload | | Scheduled/unattended operation | A configured, properly-permissioned service account | | CLI | A trusted option, key, or configured account | Person-delegated work executes as the mapped person — never as a service account standing in for them. Service accounts are for work not bound to any person, and a caller can never select service-account execution as a workaround for their own access. The runner contains no origin policy; it only enforces that the resulting account is explicit, real, active, and restored. ** Unchanged from the original scope** - The executor MUST be a real, loadable, active Drupal user entity. - No synthetic users; no temporary role mutation at runtime. - External callers MUST NOT choose the executor; outside-in entry points resolve it server-side from authenticated credentials and trusted configuration, and MUST reject or ignore caller-supplied identity fields. - Revision authorship and access checks use the executor. - All context switching uses core `account_switcher` (or a documented equivalent) and always restores in `finally`, including nested execution. - A missing, invalid, or blocked executor fails closed before any tool execution. - No silent fallback to `\Drupal::currentUser()` when an executor reference is present. **What moved out, and where it lives now** - **Subject / acting-application / authorization-ceiling contract** — being defined at the initiative level as mechanism-neutral requirements ([#3576908](https://git.drupalcode.org/project/ai_initiative/-/work_items/3576908), section 2); a transport-neutral home will be proposed with the initiative's authorization mechanism recommendation. This issue is scoped to conform to that contract and become its first adopter without waiting for it. - **Initiator as a required concept** — demoted to optional correlation metadata. It is useful provenance but not a security identity; see [#3557417](https://git.drupalcode.org/project/ai_agents/-/work_items/3557417), where the caller-supplied initiator value must be explicitly untrusted. - **Modality and policy profiles** — consumer policy, not execution identity. - **`run_id`, `thread_id`, `correlation_id`, `caller_run_id`, `environment_id`, `source`** — run/observability metadata: [#3533109](https://www.drupal.org/project/ai/issues/3533109). - **`mode: execute|simulate`** — preview semantics: [tool #3558037](https://git.drupalcode.org/project/tool/-/work_items/3558037). - **Token replacement/token-context rules** — the token and authorization layer, part of the initiative mechanism recommendation. - **Audit event schema and "via agent" display** — [#3533109](https://www.drupal.org/project/ai/issues/3533109) and its consumers. - **Vocabulary (Subject, Actor, Authorization)** — the initiative glossary ([#3577844](https://git.drupalcode.org/project/ai/-/work_items/3577844)). "Executor" remains the runtime term for the active Drupal account; "Execution Principal" remains an alias. **Definition of done / acceptance criteria** - [ ] A serializable executor reference can be carried in queue items and Messenger messages. - [ ] A shared runner service loads and validates the account; missing, deleted, or blocked executors fail before operation execution. - [ ] Account context is restored on success, exceptions, and nested execution. - [ ] `AiAssistantApiRunner` uses the shared runner rather than owning separate switching behavior. - [ ] At least one queue-worker path propagates and enforces the executor end to end. - [ ] Outside-in request payloads cannot override the server-resolved executor (negative test). - [ ] A run dispatched with an invalid executor halts before any tool execution (negative test). - [ ] No silent `currentUser()` fallback when an executor reference is present (negative test). - [ ] A person-delegated run never executes as a service account (negative test). - [ ] Access checks evaluate against the executor; created revisions and owned entities attribute the executor. - [ ] No runtime role mutation or synthetic account construction is introduced. **Alignment with in-flight work** - [#3518167](https://git.drupalcode.org/project/ai_agents/-/work_items/3518167) / MR !87: the current MR stores a real executor and switches accounts — a partial adopter of this contract. Reconcile its `scheduled` handling with the boundary table above; person-delegated runs execute as the mapped person. - [#3557417](https://git.drupalcode.org/project/ai_agents/-/work_items/3557417) / MR !283: the free-form initiator value is correlation metadata only — mark it explicitly untrusted, or replace it with typed, server-resolved metadata. - [mcp_server #3585912](https://git.drupalcode.org/project/mcp_server/-/work_items/3585912): the same fix shape at the STDIO boundary — resolve a real account server-side or fail closed. **Explicit non-goals** This issue does not standardize run observability, agent identity or provenance schemas, delegation-grant semantics, token issuance or exchange, audit storage, or "on behalf of" display. Those are real concerns owned by the issues linked above. > Related issue: [Issue #3518167](https://www.drupal.org/node/3518167) > Related issue: [Issue #3575927](https://www.drupal.org/node/3575927)