Inside AI and Outside AI: Drupal's Split AI Roadmap

A note on where I sit before going further: I contribute to the Drupal AI Initiative, maintain modules in its ecosystem, am listed among the maintainers of the AI module, and Vardot is a Gold Sponsor of the initiative as well as one of the sponsoring organizations behind the AI Content Review module discussed below. Everything below should be read with that interest on the table.

What Did the Drupal AI Initiative Actually Split Into?

The Drupal AI Initiative divided into two workstreams on 25 June 2026, each with its own lead. Inside AI covers AI inside Drupal for the people using it: assistants, in-product workflows, page building, and the rest of the user-facing surface, under Christoph Breidert.

 Outside AI covers external agents that need to connect to Drupal, inspect it, change it, verify it, migrate into it, or launch it, under Scott Falconer.

Dries Buytaert drew the line more plainly in his post the same day: 

"With Inside AI, a person uses Drupal, and Drupal uses AI to help. With Outside AI, a person uses an agent, and the agent uses Drupal."

The initiative behind both now spans 32 organizations and more than 50 contributors, with more than $2.3 million in committed funding as of 31 July 2026.

That is the split. What each half is actually up against is the more interesting question.

Why Is Outside AI the Half That Matters for Public-Sector and Nonprofit Buyers?

Enterprise procurement is already asking the question: when an AI agent writes to our CMS, what governs it? Inside AI answers a question about productivity, and that question matters. This one shows up in a risk register.

For a health ministry, a UN agency, or a foundation operating under donor reporting obligations, "the model decided" is not a defensible answer to an auditor. 

"The agent held this role, the write passed these access checks, it entered this workflow state, and here is the revision trail" is.

That is the Outside AI case in its own words: Drupal already holds "structured content, relationships, roles and permissions, editorial workflows, configuration management, APIs, and migration," and external systems should call into that rather than rebuild it.

There is a cost argument underneath the compliance one. Every agent integration built outside the CMS is a second governance system your team has to maintain, patch, and evidence at audit time. Two permission models drift, and the drift usually surfaces at audit time rather than at build time.

What Does "Governed" Have to Mean Concretely?

Governed means an agent's write is subject to the same authorization, workflow, and revision machinery as a human editor's, and that the record of it survives the action. Anything short of that is an API with good intentions.

The study compresses the same requirement into three nouns, and that version is the one that travels into a risk register: "a grant that is scoped, an action that is attributed, a denial that is auditable." 

Whichever identity model a site ends up running, the substrate has to supply all three.

Drupal already has most of the primitives. Reading Falconer's 23 July 2026 study of agent behavior against real Drupal sites, the primitives that already work group into five:

• JSON:API exposes entities under consistent authorization policies
• Entity access checks apply uniformly across entry points
• Content moderation enforces workflow states on transitions
• Revision history supports rollback
• Configuration exports to files, so config changes are reviewable in version control

The gaps in the same study are the part that makes those primitives reachable by a non-human actor, and several of them were observed directly in those runs. They group into five:

• Agent identity is unresolved. An agent can act as a delegate carrying a scoped slice of the authority of the person it works for, or as an independent non-human account with grants of its own. 
  The study treats both as legitimate, expects teams to choose differently, and notes that the same site may run both. What neither model has yet is substrate support, so scoped, auditable agent identity is incomplete either way.
• An agent cannot discover what it may do, or what there is to do. There is no machine-readable inventory of site structure, roles, and permissions, so an agent cannot establish what it is allowed to do before attempting it. 
  Operations beyond create, read, update, and delete compound the problem: cache clearing, recipe application, and migrations live across inconsistent endpoints with no unified action model declaring inputs, outputs, and authorization.
•  No core contract declares that catalog, so an agent cannot discover those operations the way it can discover entity CRUD.
• Configuration records what was decided, not why, and where the why exists, nothing enforces it. In the study's recipe-composition tests, two recipes applied conflicting config actions to the same property and the later action won mechanically. 
  In the intent experiments, an agent read the stored reasoning behind a design decision and then removed the very affordances that reasoning was meant to protect. Rationale is missing in most places, unenforced in the rest, and the last writer wins.
• Custom code can bypass declared permissions at the config and code boundary. The study puts the whole problem in one sentence: "Configuration declares a desired state that one line of code can silently bypass." The observed case was custom code calling
   ->accessCheck(FALSE) 
• on an entity query and then exposing the entities without an entity-access check.

• Human review does not survive agent volume. Agents generate change at a rate editorial review was never sized for, and the study is blunt about what follows: "Human review alone does not survive that volume. 
  Independent, automated verification has to absorb it." A revision trail is necessary and not sufficient, because at agent scale something other than a person has to read it.

  Automated review is arriving, but on the assistance side and at the content layer. The AI Content Review module, in alpha since 17 September 2026, scores content against configurable criteria, applies pass and warning thresholds, and keeps append-only review records per entity. 
  That is real, and it is not the verification this gap describes.

   The gap it names sits a layer down, where "a site's true behavior is the intersection of config and code, and verification that reads only one layer misses the other." As far as I can find, nothing yet reads both.

The install numbers say the same thing in a different language. As of 23 September 2026, Drupal's AI module reports 21,492 sites, with 1.4.9 stable and 1.5.0 in release candidate. 
The MCP Server module, the most direct route an external agent takes into Drupal, reports 1,305 and sits at 2.0.0-beta4 with no supported stable release. Demand for AI in Drupal is in production. The governed path for external agents is still being built.

Where the Risk Actually Sits

The split is not two halves of one product. The two workstreams answer different questions, and they are running on different clocks.

Inside AI is working in the most crowded part of the market, where every CMS is shipping an editorial assistant.

The 2026 roadmap gives it eight capability areas, from page generation and content creation through to advanced governance, and an editor can see the result of every one of them. That is feature work with a visible scoreboard.

Outside AI is building something no CMS has yet. Its roadmap maps an agent's journey through a site in five stages:

1. Start and connect
2. Understand the running site
3. Act through governed interfaces
4. Verify and recover
5. Rebuild, migrate, and launch

That is infrastructure rather than product, and infrastructure shows its value later than features do.

The roadmap leaves one thing open that matters more than the rest. Both identity models are legitimate and the same site may end up running both, but the five stages describe a journey rather than a delivery order, so nothing yet says when identity gets settled or which model arrives first.

That silence is the risk, because delegation is the easier build and easier builds arrive first without anyone deciding they should. Until the substrate can attribute an action to a non-human actor, delegation collapses the agent's write into a human's identity, and the revision trail reports that a person made a change that person did not make.

On a commercial marketing site, that is untidy. For a health ministry or a UN agency it is a defect, because the entire purpose of the trail is to separate who acted from what acted, and under whose authority. 

Which is why attribution is the thing to watch for in the substrate, and the thing to ask about before you connect an agent to a governed site.

Attribution alone is not the finish line either: at agent volume the trail gets read by machines or not at all, which puts automated verification inside the governance story rather than at the end of it.

There is a second reason not to wait for the roadmap to settle this, and it is the one I would act on. Agents form habits faster than roadmaps ship. 

External agents are already reaching Drupal through whatever they can already touch, and a governed interface that arrives later inherits those workarounds rather than a clean slate.

Which is why the work that decides your outcome sits on your side of the boundary, not the initiative's.

Who Should Not Be Building Toward Agent Access Yet?

Most organizations evaluating agent access should not start with agent access, and some should not start at all this year. Four cases where the honest answer is to spend the budget elsewhere.

If Your Content Model Is Not Structured Yet

An agent writing into an unstructured content model produces the same mess faster and with a better audit trail. Fix the model first. This is content architecture work, not agent work.

If You Are Still on Drupal 10

Drupal 10 reaches end of life on 9 December 2026. The deadline is harder than it looks: 10.6.x is the last Drupal 10 minor, its security coverage ends the week of 7 December 2026, and sites on 10.5.x lost security support the week of 29 June 2026. 

The upgrade is the governance work this year, and nothing about agent access is worth delaying it for.

If Nobody Will Ever Ask You for the Trail

If no auditor, funder, or regulator is going to ask which non-human actor made a change and under what authority, you are buying governance you do not need. Inside AI is the cheaper answer to your actual problem.

If What You Want Is Editorial Assistance

If the use case is drafting, translation, or alt text, that is Inside AI, it is available now, and the Outside AI roadmap is not your dependency.

Two of these four cases mean less work for an agency like ours, and they are still the right call.

What Should an Evaluating Team Do Before the Roadmap Lands?

Five questions, answerable this quarter from facts you already hold, tell you whether agent access is a near-term option or a 2027 conversation. None of them require a vendor.
 

Can You Name Today Which Roles an External System Would Hold on Your Site?

If the answer is "we would create one and see," your permission model is not ready for a non-human actor. The roles have to exist, and their grants have to be scoped, before anything non-human holds one.

Which Write Paths on Your Site Skip Validation?

Core is better here than it usually gets credit for. Writes arriving through Drupal's standard web APIs run the same validation the editorial interface does, so a workflow transition that is not permitted is refused there too. 

The gap sits below that. Custom code, deployment scripts, migrations, and background jobs can write content directly, skipping validation entirely, and no workflow state is enforced on any of those paths. An agent handed a custom endpoint or a shell is on exactly that path. Inventory those callers before you inventory anything else.

Can You Produce a Revision Trail That Identifies a Non-Human Actor?

Not "a change happened," but which account, acting for whom, under which grant. If your trail cannot express that distinction, it cannot evidence agent activity to an auditor.

Does Any Custom Code in Your Codebase Bypass Declared Entity Access?

This is a grep and a code review, not a project. Start with 

grep -rn "accessCheck(FALSE)" web/modules/custom, 

then check whether each result applies an entity access check afterward. It is also the most direct way a governed interface turns out not to be governed, because the bypass sits below the layer everyone audits.

Is Your Content Model Structured Enough for a Machine-Readable Inventory to Tell an Agent Anything Useful?

If your editors work in one long body field, the answer is no. An inventory of a single unstructured field gives an agent nothing it can act on safely.

What the outcomes mean 

• Answer yes to four or five and you are in a position to run a scoped read-only pilot now, ahead of the roadmap, and to give the initiative useful feedback. 
• Answer yes to two or three and the work in front of you is access hygiene, not AI.
•  Answer yes to one or none and agent access is a 2027 question, and pretending otherwise just moves the risk somewhere you cannot see it.

What Is the Useful Next Step?

If you are evaluating what agent access would mean for a governed publishing environment, the useful next step is an access and content model review against those five questions, not an AI project. 

Vardot runs that as a scoped Drupal audit, and the output is a picture of your own install rather than a recommendation to build something.

We help build this initiative, and we will still tell you when the honest answer is that your own groundwork comes first.