> **Updated July 23, 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 23, 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; a denied or invalid action fails with structured feedback; and every attempt is attributable to the resolved Drupal executor, the initiating subject when present, and the acting agent or application. Outside AI requires four distinct concepts: the subject whose authority is requested, the real Drupal account that executes the operation, the agent or application acting on the subject’s behalf, and a bounded delegated grant. Effective authority is the intersection of the executor’s current contextual Drupal access, the delegated grant, and site safety policy. For person-delegated work, the subject is the authenticated human and must resolve at a trusted server-side boundary to that person’s active Drupal account. For unattended work, the subject may be a configured service principal. Revisions are authored by the resolved Drupal executor; the acting application and grant are retained separately as provenance. [RFC 8693](https://www.rfc-editor.org/rfc/rfc8693.html) defines token exchange and subject/actor vocabulary, including the `act` claim. It does not define Drupal identity mapping, require permission intersection, or determine revision authorship. Those are product and Drupal authorization invariants we must establish. The initiative’s requirements for whatever mechanism is backed, stated mechanism-neutrally: 1. A person can delegate a bounded scope of their own access to an agent and revoke it at any time; revocation takes effect on the next request. 2. The agent can never exceed the person’s current contextual access. Effective authority is the intersection of the person’s live Drupal access and the delegated scope; the delegation layer itself grants nothing. 3. Actions are done by the person — access checks run as them, revisions are authored by them — with the acting agent recorded from its authenticated identity. Anything a request merely claims is retained only as clearly-marked unverified metadata, never as identity. 4. Denied actions fail with Drupal’s standard structured feedback; the remedy is normal administration, evaluated per request. 5. Service accounts exist only for work not bound to any person, are configured by administrators, are attributed to themselves, and can never be selected by a person as a workaround for their own access. A recommendation for which mechanism the initiative backs — building on the existing OAuth modules, or a lightweight spec-first layer that existing modules integrate with — is being prepared requirements-first, following the same pattern as the MCP server decision. - [Propagate and enforce an explicit executor for sessionless, queued, and outside-in AI runs #3573899](https://git.drupalcode.org/project/ai/-/work_items/3573899) — **Accepted; re-scoped July 23.** Now owns the narrow, implementable contract: an explicit executor selected at a trusted boundary, carried across queue, cron, and Messenger boundaries, activated through core account switching with guaranteed restore, and enforced fail-closed with negative tests. Executor selection is bound to origin — person-delegated runs execute as the mapped person; configured service accounts are only for work bound to no person; callers never choose. The broader subject/actor/authorization contract is tracked through the requirements above and the mechanism recommendation; this issue is its first adopter. - [Add a way to mark the executor on agent runner #3557417](https://git.drupalcode.org/project/ai_agents/-/work_items/3557417) / [MR !283](https://git.drupalcode.org/project/ai_agents/-/merge_requests/283) — **RTBC, but not yet aligned with this contract.** The patch accepts a caller-supplied free-form `initiator` string. That can be useful correlation metadata, but it is not trusted identity, executor resolution, or authorization provenance. Before merge, align the terminology with #3573899 and either mark this value explicitly untrusted or replace it with typed, server-resolved execution metadata. - [STDIO tool calls execute without an authenticated user #3585912](https://git.drupalcode.org/project/mcp_server/-/work_items/3585912) — **Open discovery issue.** Current STDIO execution appears anonymous, so permission-gated tools fail. No implementation has been selected. Supported options include keeping STDIO anonymous and limited to public tools, or adding explicit operator-controlled binding to a real account. In either case, missing identity must fail closed; it must not produce an elevated fallback. Implementation routing: active MCP server work belongs to the `mcp_server` family, not the legacy `mcp` project. The 2.x architecture separates protocol/runtime, OAuth, Tool API bridge, and UI into companion projects. - [MCP Server OAuth](https://www.drupal.org/project/mcp_server_oauth) — **1.x-dev; no tagged release.** This is the current OAuth scope-enforcement implementation for `mcp_server`, replacing the direction represented by legacy `mcp` issue #3569845. It provides OAuth authentication and per-tool scope enforcement, but it does not yet provide complete subject/actor delegation. - Authenticated MCP HTTP request to Drupal executor and grant — **Gap; no canonical issue exists.** File this against `mcp_server_oauth` and link it to #3573899. Acceptance criteria should include validating issuer, exact site/environment audience, signature and expiry; resolving the subject server-side to an active Drupal account; enforcing Drupal access ∩ delegated grant ∩ tool policy; retaining actor/client provenance separately; authoring revisions as the executor; and rejecting caller-supplied UIDs, blocked users, role mutation, and elevated fallback. - [Decouple TokenUserInterface from Oauth2TokenInterface #3507076](https://www.drupal.org/project/simple_oauth/issues/3507076) — **Active proposal; no merge request.** It would let downstream consumers inspect scopes without depending on a stored token entity. That is useful enabling work, but it neither carries a complete delegated grant nor enforces the authorization intersection by itself. - [Client Credentials user-assignment semantics #3590930](https://www.drupal.org/project/simple_oauth/issues/3590930) — **Active; no merge request.** Role scopes appear intersecting while permission scopes may be additive. This needs a decision and contract tests before either behavior becomes product truth. No scope may broaden a person-delegated user’s current Drupal authority. Client credentials belongs to the unattended service-account path, not human delegation. - [OAuth 2.0 Token Exchange](https://www.drupal.org/project/simple_oauth_token_exchange) — **1.0.0-rc1; no supported stable release.** Its documented use is exchanging an existing token for one with narrower or different scopes in the same client. It is a useful reference or spike, not yet a proven Outside AI dependency. There is no linked upstream stable-release or actor-claim issue, so those are candidate follow-ups rather than active planned work. - [Let an agent use a role when running a tool #3518167](https://git.drupalcode.org/project/ai_agents/-/work_items/3518167) / [MR !87](https://git.drupalcode.org/project/ai_agents/-/merge_requests/87) — **Needs work; the issue summary is stale.** The current MR no longer creates synthetic users or mutates roles. It stores a real executor UUID and switches accounts for non-interactive agents, making it a partial adopter of the desired model rather than a wholesale conflict. Before merge, fix the entity-autocomplete validation bug, restore green PHPUnit and PHPStan jobs, reconcile its `scheduled` modality with #3573899, and do not treat every outside-in run as service-account execution. Person-delegated outside-in work must execute as the mapped human. ### 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. A configuration-level complement is now in testing. Configuration records what a site is; it does not record why. When an agent modifies an unfamiliar site, the reasoning behind load-bearing configuration is exactly what it cannot see, and a site degrades through many small changes that are each locally reasonable but wrong for the site’s purpose. - [Intent](https://www.drupal.org/project/intent) — **New; no tagged release; testing commitment.** Attaches plain-language rationale to configuration (third-party settings on configuration entities, with a CLI for reading and writing it) so an agent reading live or exported configuration sees the reasoning behind a setting, not just its value. Early testing suggests intent annotations substantially reduce harmful agent modifications; that result needs independent, repeatable verification before it becomes a roadmap claim. The annotations module addresses the human-facing side of the same need and should stay aligned as a natural producer of the same data. - Align the AI initiative demo recipes with intent — **Agreed direction with the Inside AI demo effort; not yet an issue.** As the demo is consolidated into curated recipes, those recipes should carry intent annotations and agent-readable documentation, so applying the demo produces a self-describing site rather than configuration whose reasoning was lost at apply time. This is the first concrete test bed for whether intent measurably improves agent behavior across many small decisions. ### 4. Act through governed interfaces **Standard:** Agents can discover an operation and its declared inputs and effects before invoking it. When they execute it, Drupal applies its normal access, validation, workflow, and policy checks and returns a machine-readable outcome. This does not require a universal preflight permission oracle. - [Tool API path to beta and inclusion in AI #3558327](https://git.drupalcode.org/project/tool/-/work_items/3558327) — **Accepted; sprint-tagged.** This is the primary implementation umbrella for shared tool definitions and execution. Its current checklist does not define a structured execution-result and error contract, so machine-readable validation, authorization, conflict, and retry semantics must not be treated as shipped. - [Make Tool declarations introspectable over the CLI and enrich input schema #3582943](https://git.drupalcode.org/project/tool/-/work_items/3582943) — **Open / To do; no estimate or merge request.** This currently combines independently shippable schema and operational-metadata work and needs to be split before estimation. Static declarations and unmet requirements can be surfaced, but a generic list of “required permissions” must not be presented as an executability oracle. Access can depend on the account, inputs, entity state, workflow, grants, and site policy. - MCP Server convergence — **In transition.** The tagged release remains `mcp_server` 2.0.0-alpha1; current 2.x development separates protocol/runtime, [Tool API bridge](https://www.drupal.org/project/mcp_server_tool_bridge), [OAuth](https://www.drupal.org/project/mcp_server_oauth), and UI into companion projects. Those companion projects are unreleased. [Tool UI migration #3568162](https://git.drupalcode.org/project/mcp_server/-/work_items/3568162) remains Accepted and sprint-tagged, but MR !5 has a failed pipeline and predates the project split. Its remaining work should be moved or split into the appropriate bridge and UI projects before it remains a roadmap implementation anchor. - Structured Tool execution result and error envelope — **Not yet filed.** This is a blocking contract gap, not something solved by catch-all exception handling. The issue should define stable outcomes for success, authorization denied, validation failed, policy denied, conflict, rate limiting, transient failure, and partial failure. Each outcome should include a safe message, permitted field errors, retryability, correlation or audit ID, and safe next action. Drupal’s normal access and validation APIs remain authoritative; raw exception text is not the contract. The target direction is convergence where appropriate: Tool API owns transport-neutral definitions, execution behavior, and result semantics, while CLI, MCP, and other consumers expose them through the transport appropriate to their environment. That convergence is not complete today. ### 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 #3558037](https://git.drupalcode.org/project/tool/-/work_items/3558037) — **Postponed / needs information.** It is the existing issue for preview mode, but its current proposal requires each write-capable tool to detect preview mode and suppress its own side effects. It therefore does not yet define reliable generic dry-run semantics. Preview should be developed for reviewable or high-risk writes; it is not a prerequisite for ordinary execution feedback. Execution feedback and independent verification are separate contracts. Execution feedback reports whether Drupal accepted or rejected an operation and why — for example, attempting to save content without a required field produces a structured validation failure and nothing is saved. Independent verification then reads site state back and proves whether the intended result exists. A successful execution receipt proves only the first. ### 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 #3573022](https://git.drupalcode.org/project/canvas/-/work_items/3573022) — **Closed/fixed on July 22; [MR !1360](https://git.drupalcode.org/project/canvas/-/merge_requests/1360) merged.** Canvas now blocks configuration imports that would delete an in-use component or its backing configuration. This is a Canvas-side mitigation. The underlying `ConfigImporter` lifecycle problem remains [active in Drupal core #3610722](https://www.drupal.org/project/drupal/issues/3610722) and should remain linked if Canvas is selected for the proof path. 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.