> **Updated July 13, 2026.** This is the living control issue for the Outside AI workstream. It replaces the earlier “Outside-in / Innovation” framing with an outcome-based roadmap. > > The issue links below are a deliberately small working set, not an exhaustive dependency map. We will refresh them as work lands, moves, or is replaced. The linked queues remain authoritative. Linking an issue here does not change its owner, priority, milestone, or technical direction. > > The previous detailed ticket inventory remains available in this issue’s edit history. Work not carried forward is not being declared obsolete; it is simply not a current headline Outside AI commitment. ## Problem / motivation Outside AI covers the path where a person uses an external agent, builder, or orchestration system, and that system uses Drupal. **Inside AI:** a person uses Drupal, and Drupal uses AI to help. **Outside AI:** a person uses an agent, and the agent uses Drupal. Drupal already has many of the capabilities agents need for serious sites: structured content, relationships, roles and permissions, workflows, configuration management, APIs, and migration. The problem is that agents often work too hard to reach those strengths. Setup choices, authentication, stale assumptions, unclear action surfaces, and weak verification can consume the session before Drupal’s advantages become visible. When that happens, the agent works around Drupal, produces something that only looks finished, or silently chooses another path. The goal of [Outside AI](https://dri.es/launching-drupal-outside-ai-workstream) is to make Drupal legible, callable, safe, and verifiable from the outside. The north star is: > Drupal becomes the clearest, most trustworthy CMS choice for an external agent building a real, governed site. ## Scope and ownership Outside AI owns: - The end-to-end external-agent journey and its acceptance criteria. - Reference workflows that exercise that journey. - Evidence showing where the path succeeds or fails. - Measurement through the Drupal Agent Readiness Scorecard. - Coordination across the projects and teams needed to close confirmed gaps. Outside AI does not automatically own every implementation required by that journey. Work that belongs in Drupal core, contrib, Drupal CMS, Canvas, hosting products, or another initiative remains in its natural project and follows its normal governance. Inside AI owns the in-product AI experience. Drupal CMS owns templates, starting points, and its product surface. Outside AI owns whether external agents can reliably discover, use, adapt, verify, export, and launch those surfaces. ## What done looks like A bounded external-agent workflow should be able to: 1. Start from a supported Drupal path. 2. Connect with scoped, auditable authority. 3. Understand the running site without scraping the UI or guessing from stale knowledge. 4. Act through typed, governed interfaces. 5. Independently verify the result and recover when it fails. 6. Produce a defensible build, adaptation, migration, or launch handoff. Measurement is the spine across all six. The agent’s own statement that it succeeded is not proof. ## Current focused work Status snapshot: July 13, 2026. ### 1. Start from a supported Drupal path **Standard:** An agent can begin useful work without spending the session choosing between undocumented setup paths or inventing its own Drupal workflow. - [Core CLI entry point roadmap to stable](https://www.drupal.org/project/drupal/issues/3606055) — **Active.** This is the current parent for the dr command and its path to stability. Agent-specific requirements should feed this roadmap rather than create a parallel CLI meta issue. ### 2. Connect with scoped, attributable authority **Standard:** An allowed action succeeds, an out-of-scope action fails clearly, and both are attributable to the agent and initiating actor. The direction here has firmed up. We follow the model major platforms converge on for app-acts-for-user access: a **subject** (whose authority is exercised — a real Drupal account), an **invoker** (which application or agent is acting), and an **authorization ceiling** that can only narrow the subject's access, never extend it — effective access is always the intersection. This is the vocabulary of RFC 8693 (token exchange, `act` claim), not an AI-invented one. Attribution follows from it: revisions are authored by the subject; the invoker is recorded as provenance. - [Define the Execution Principal contract](https://git.drupalcode.org/project/ai/-/work_items/3573899) — **Accepted; being narrowed.** This issue is being re-scoped to what sessionless AI execution concretely needs: an explicit executor selected at a trusted boundary, propagated across queue, cron, and Messenger boundaries, activated through core account switching with guaranteed restore, with access checks and revision authorship using that account — no synthetic users, no runtime role mutation, callers never choose their own executor. The broader subject/invoker/authorization contract is transport-neutral auth infrastructure rather than an AI-module concern; a separate plan issue will propose where it lives, with this issue as its first adopter. - [STDIO tool calls execute without an authenticated user, so permission-gated tools fail](https://git.drupalcode.org/project/mcp_server/-/work_items/3585912) — **Open.** The live instance of the problem this section exists to fix, in the MCP server implementation this initiative is backing. The fix shape follows the contract: resolve a real account server-side and fail closed — never an anonymous run, never an elevated fallback. - [Decoupled TokenUserInterface from Oauth2TokenInterface](https://www.drupal.org/project/simple_oauth/issues/3507076) — **Active.** Lets downstream consumers read validated scopes without depending on a stored token entity — the prerequisite for carrying an authorization ceiling into sessionless execution. - [OAuth 2.0 Token Exchange (RFC 8693)](https://www.drupal.org/project/simple_oauth_token_exchange) — **1.0.0-rc1.** Testing toward a stable release; a follow-up will propose the standard actor (`act`) claim so "acting on behalf of" becomes representable in tokens rather than in log text. One open proposal conflicts with this section's standard and should be resolved against it: [Let an agent use a role when running a tool](ht ### 3. Understand the running site **Standard:** Given an unfamiliar Drupal site, an agent can discover its structure, capabilities, constraints, and safe action paths through supported machine-readable surfaces. - [Add Site Architecture context source for Drupal site behavior contracts](https://git.drupalcode.org/project/ai_context/-/work_items/3586150) — **Postponed.** This remains the clearest existing issue describing the site-understanding gap, but it is not currently an active delivery commitment. A postponed issue is evidence that the gap is known. It is not evidence that the capability has shipped. ### 4. Act through governed interfaces **Standard:** Agents can discover an operation before invoking it, understand its inputs and effects, pass authorization checks, and receive a machine-readable result. - [Tool API path to beta and inclusion in AI](https://git.drupalcode.org/project/tool/-/work_items/3558327) — **Accepted.** This is the primary umbrella for the shared action surface. - [Make Tool declarations introspectable over the CLI and enrich input schema](https://git.drupalcode.org/project/tool/-/work_items/3582943) — **Open.** This lets consumers understand tools, inputs, effects, access, and requirements before execution. - [Tool UI migration from MCP module](https://git.drupalcode.org/project/mcp_server/-/work_items/3568162) — **Accepted; sprint-tagged.** Consolidates the MCP surface on mcp_server, which is built on Tool API — tool metadata, access, and scopes get defined once and exposed per transport rather than reimplemented per protocol. - The direction is convergence where appropriate: Tool API defines shared action metadata and behavior, while CLI, MCP, and other consumers expose those actions through the transport that fits their environment. ### 5. Verify and recover **Standard:** An independent process can confirm what changed, determine whether the intended result exists, and identify the available preview, repair, rollback, or human-handoff path. - [Allow Tool execution to be previewed](https://git.drupalcode.org/project/tool/-/work_items/3558037) — **Postponed / needs information.** This is the current home for concrete preview and dry-run semantics. We should answer the missing questions here before filing a parallel meta issue. Preview is only one part of verification. A successful tool receipt shows that an operation ran; it does not independently prove that the desired site outcome exists. ### 6. Build, adapt, migrate, and hand off **Standard:** A real workflow produces a Drupal-native result with inspectable architecture, independent verification, explicit gaps, and a handoff another person or agent can continue safely. - [Canvas configuration import data loss and bypassed integrity checks](https://git.drupalcode.org/project/canvas/-/work_items/3573022) — **Accepted / Critical.** If Canvas is part of the selected proof path, normal configuration deployment must not delete component configuration or bypass integrity checks. The next control decision is to select one bounded proof path: prepared-site adaptation, build-to-launch, or migration-to-launch. Until that decision is made, this issue should not accumulate a large speculative migration, Canvas, hosting, and deployment dependency tree. Migrate API remains the supported path for structured migrations. Outside AI is concerned with agent-led re-architecture and handoff where interpretation and architectural judgment are required. These paths may work together; one does not replace the other. ## Measurement and Rotterdam proof The [Drupal Agent Readiness Scorecard](https://github.com/scottfalconer/drupal-agent-readiness) should tell us whether Drupal improved while the workflow remained stable, separately from normal improvements in models and agent products. There is not yet a canonical Drupal.org issue for the complete measurement spine. Until one is filed, this meta issue should state the requirement without pretending an adjacent ticket covers it. Measurement should use: - Fixed, versioned tasks. - Real running sites. - Retained runs, failures, and nulls. - Independent checks rather than agent self-report. - Recorded environment, model, tool, and evaluator versions. - Paired before-and-after runs before attributing improvement to Drupal. Rotterdam should prove direction, not victory. The proof should demonstrate one bounded end-to-end path: - Supported start. - Scoped connection. - Correct understanding of site reality. - A useful governed change. - Independent verification. - A declared recovery posture. - A reviewable handoff artifact. - Explicit manual steps and unresolved gaps. One successful run demonstrates feasibility in that case. A second independent run begins to test repeatability. Neither proves market adoption, and we should not claim otherwise. ## Bring us real work Outside AI needs real workflows more than speculative feature lists. If you are: - Using an external agent to build or change a Drupal site. - Calling Drupal from another system. - Rebuilding or migrating an existing site into Drupal. - Maintaining a project agents repeatedly misunderstand. - Working around the same Drupal limitation in prompts, scripts, or glue code. - Seeing an agent silently bypass Drupal’s native capabilities. Bring us the real task. A use case, failed run, repeated workaround, missing capability, or link to an existing issue is enough. You do not need to arrive with a solution or know which project owns the work. Please include whatever you can provide: 1. The task you were trying to complete. 2. The agent, tool, Drupal version, and environment used. 3. What you expected to happen. 4. What happened instead. 5. The workaround, if any. 6. Reproducible evidence or sanitized logs. 7. Any existing issue that may be related. We will help reproduce it, map it to the agent journey, connect it with the appropriate maintainers and implementation work, and determine whether it belongs in the scorecard or roadmap. Wherever external tooling has to explain the same Drupal quirk repeatedly, that workaround is a requirements document. Discussion also happens in the #ai-initiative channel in Drupal Slack.