> ⚠️ **Postponed pending approval.** Part of the [Chat Fundamentals plan](https://git.drupalcode.org/project/ai/-/work_items/3586640); awaits maintainer approval ([approval issue](https://git.drupalcode.org/project/ai/-/work_items/3586639)). Targets the **1.6.x branches of ai and ai_agents once created**. Strictly opt-in. **Depends on (ai project):** [tool annotations (#3586642)](https://git.drupalcode.org/project/ai/-/work_items/3586642), [elicitation contract (#3586646)](https://git.drupalcode.org/project/ai/-/work_items/3586646). ### Problem/Motivation `AgentToolPreExecuteEvent` (`ai_agents.tool_pre_executed`) is dispatched immediately before `$tool->execute()` in `AiAgentEntityWrapper` (~line 1771) — exactly the right moment for human-in-the-loop control — but the event is observe-only. Nothing can stop a destructive tool call. "Yes/no before the agent deletes 10 entities" currently requires forking the agent loop. Two building blocks are provided by the ai-side child issues: MCP tool annotations on definitions (#3586642 — with the spec's conservative default that an *unannotated* tool is assumed destructive), and the elicitation round-trip (#3586646 — pause the turn, ask the user, resume). MCP itself treats tool confirmation as a host/client duty, but since our clients are simple polling frontends, reusing the elicitation wire shape for confirmation is the pragmatic, spec-adjacent design. ### Proposed resolution **Make the event actionable** (additive methods on `AgentToolPreExecuteEvent`): - `setVeto(string $reason): void` / `isVetoed(): bool` / `getVetoReason(): ?string` - `setElicitationRequest(ElicitationRequest $request): void` / `getElicitationRequest(): ?ElicitationRequest` **`AiAgentEntityWrapper` honors them after dispatch:** - **Veto** → skip execution, synthesize a tool-role result: `"Execution of {tool} was denied: {reason}"`. The loop continues and the model adapts. - **Elicitation** → pause the loop, persisting agent state via the existing tempstore machinery (the pause/resume infrastructure `AgentRunner::runAsAgent()` already uses across polling requests in ai_assistant_api), and bubble the request up to the processor (`getPendingElicitation()`, #3586646). **Confirmation request shape:** - The human-readable `message` is **generated from the trusted tool definition** (label/description from the `FunctionCall` attribute), never from LLM output — mirroring the MCP elicitation security note that the user must see *who* is asking via a trusted channel. - Tool identity and arguments ride `_meta['drupal.org/ai.tool_call'] = {name, toolId, arguments, annotations}` so a frontend can show exactly what would run, with which arguments. - `requestedSchema` is minimal: `{type: "object", properties: {instructions: {type: "string", description: "Optional instructions if you want the agent to do something differently"}}}`. **The yes/no is the elicitation `action`, not a schema field.** **Result semantics:** - `accept` → execute the tool (optionally passing `instructions` back to the model context). - `decline` → do not execute; synthesize a tool result `"User declined execution of {name}: {instructions}"` and **feed it back to the model** so the loop continues and the agent can adapt or offer an alternative (costs one extra model turn; chosen over hard-stop). - `cancel` → abort the iteration. **Gating configuration — opt-in per agent + tool combination.** Ship a config-gated `ToolConfirmationSubscriber`: - Per-agent master toggle: "require tool confirmation" (default off — zero behavior change for existing sites). - When enabled, per-tool overrides on the agent: `always` | `never` | `by_annotation` (default `by_annotation`). - `by_annotation` follows the MCP defaults from #3586642: confirm unless `readOnlyHint: true` — an unannotated tool prompts, which is the safe reading of the spec. **Tests:** kernel tests for veto (denied tool result, loop continues), each result action (including the decline synthetic message reaching the model), gating matrix (agent off / on + per-tool override values), and double-submit idempotency via the elicitation ID. ### Backwards compatibility Event gains methods (additive). Confirmation gating is strictly opt-in per agent; nothing changes until a site enables it. **Consumer integration note:** a consumer that ignores `getPendingElicitation()` will see the turn end with a prose question; the paused state expires with the tempstore. Confirmation-capable frontends render an accept/decline UI from the MCP-shaped request. ### AI Assistance Yes, AI was used to explore the codebase and draft this issue.