Guardrails, AI migrations, MCP: what we brought to Rotterdam

DrupalCon Europe 2026 took place in Rotterdam from September 28 to October 1, 2026. The format featured three distinct moments: the first day dedicated for the first time to thematic summits, followed by the conference days, and finally the General Contribution Day. The SparkFabrik team participated in all three, bringing to the stage and the issue queues the work we do throughout the year on AI in Drupal. Our technical contributions, comprising talks, moderation, and code, span three main tracks:

• Guardrails: Luca Lusso’s talk at the AI Dev Summit on the Guardrails subsystem of the Drupal AI module, the working group on guardrails and security that he moderated, and the contribution to the issue that brought decision models into 1.6.0-dev.

• AI migrations: Roberto Peruzzo’s talk “163 → 42: Dismantling and Reassembling a Drupal Migration with AI” on the conference stage, dedicated to a large AI-assisted site migration to Drupal 11.

• MCP: the work on the MCP Client module during the General Contribution Day on Thursday, October 1.

In addition to these tracks, there was the Splash Award: with the Luiss University project, we won the International Splash Award in the Education category, the first recognition of its kind awarded to an Italian project.

Alongside our technical contributions, we attended sessions on AI, core, and the community. In Rotterdam, as we experienced it, the most concrete work on AI in Drupal focused on what surrounds the model: validating what goes in and what comes out, structuring decisions, providing context, establishing who can do what, and how connections are authenticated. These controls are built in the issue queues: anyone who wants to guide their development must bring code and proposals there.

Guardrails at the AI Dev Summit: day one started with control

For the first time at a DrupalCon Europe, the opening day of the event was dedicated to summits covering different topics, each with its own schedule. We attended the AI Dev Summit, the summit on developing AI tools within Drupal, where Luca Lusso gave a talk on the Guardrails subsystem of the Drupal AI module.

We helped develop that subsystem, which has been part of the Drupal AI module core since last year. The Guardrails framework validates AI input and output against toxic content, prompt injection, and the exposure of PII (personally identifiable information). The checks rely on regular expressions, keywords, and moderation APIs such as those from Azure and OpenAI, fitting directly into the Drupal AI module architecture that we described in our overview, alongside community initiatives.

For anyone placing an LLM in front of Drupal site users, these controls operate at two distinct moments¹. On input, they can stop a prompt that attempts to override system instructions or that contains an email address that should not be forwarded to the provider. On output, they can block a response containing toxic language before it is displayed on the page. The responsibility for control stays on the platform, regardless of which model is chosen to generate the text.

The following diagram simplifies the flow without getting into implementation details: guardrails run before and after the call to the model. Among the check types, we have also included decision models, which 1.6.0-dev makes available at precisely these stages.

The rest of the agenda followed a similar direction. Nick Veenhof presented the tools GitLab is developing to streamline and encourage open source contributions to the product codebase. Marcus Johansson showed the latest progress on the Context Control Center, a Drupal module that provides context to agents operating on the platform, much like skills, but tailored for agents working on a Drupal site. Jurgen Haas demonstrated the evolution of ECA in agentic workflows, and Shibin Das did the same with FlowDrop.

Taken together, these sessions outline a clear roadmap: control over what enters and exits the model, context on what the agent is allowed to know, workflows governing what the agent can do and in what order, and tools to make contributing easier. None of the sessions we attended focused merely on comparing one model against another.

The day ended with four breakout tables designed to explore emerging topics and brainstorm future innovations. Luca Lusso moderated the session on guardrails and AI security in Drupal, bringing to the table the direct experience of someone who wrote the subsystem code.

Decision models in Drupal AI

A regex-based guardrail reliably detects a credit card number, but struggles with prompts that require judgment. Is a request off-topic? Does a text belong to a sensitive category? Is a newly phrased prompt an attempt at manipulation? For questions like these, the most useful answer takes the form of a yes, a no, or a classification within a closed list of choices.

On September 15, 2026, TypeSafe AI released Jev, a model that returns structured outputs for decision-oriented questions, and it quickly became a hot topic within the Drupal AI module development team. About two weeks later, in time for the conclusion of DrupalCon Europe 2026, version 1.6.0-dev was released with full support for decision models, including Jev. The work is tracked in issue #3586751 of the Drupal AI module, and we also contributed to bringing this new direction of the AI frontier into Drupal.

Asking the model for a decision rather than free-form text simplifies control for a straightforward mechanical reason: the space of possible answers is closed and known in advance. If the model answers true or false, the calling code handles two branches and nothing else; if it answers with a category, the code matches it against the allowed list and discards anything outside it. A free-text response, by contrast, must be reinterpreted, perhaps through another model call, and every layer of interpretation adds an opportunity for the check to fail. With a closed output, the decision becomes verifiable: it can be logged, tested against known test cases, and used to route application logic deterministically.

This is why decision models, or classifiers, belong naturally at strategic checkpoints throughout the platform, starting with guardrails. We believe Drupal is the first open source platform currently available on the market to support decision models out of the box.

At the same conference, the talk AI-Assisted Contrib Module Maintenance offered an overview of both deterministic and non-deterministic tools used by the team behind the Drupal AI module to triage the issue queue, categorize issues, and validate merge requests. Categorizing an issue is itself a selection from a closed list. We believe these strategies can be applied to all contrib modules to help maintainers manage issue queues, work more efficiently, and write better code.

AI migrations and clean code: the LLM reasons about what it sees

On the conference stage, our Roberto Peruzzo presented “163 → 42: Dismantling and Reassembling a Drupal Migration with AI”. The talk outlined an end-to-end approach to a large, AI-assisted site migration to Drupal 11, structured into four phases: analyse, decompose, implement, assemble.

The key takeaway lies in the sequence of phases: first analyze and decompose, then implement and reassemble. In our view, this structure is what makes AI assistance manageable throughout the entire process, fully aligned with the agentic-first approach to Drupal development, which shifts value away from writing code toward defining context and specifications.

The mechanism behind this insight was described by Len Swaneveld in Clean Code in the Age of AI. His core thesis is that clean code and clean architecture serve as a form of context engineering and a safeguard against LLMs going off track, because an LLM can only reason about what it sees, and it guesses the rest. Clean code, characterized by single responsibility, meaningful naming, small functions, consistent levels of abstraction, shallow nesting, and DRY, is easier for a model to handle because it requires less context and fewer tokens. Swaneveld distinguished two scales: clean code keeps the necessary context within a small window, while clean architecture organizes it across a broad window. For architecture, the rules were precise: no business logic in hooks or controllers, dedicated services for business logic, dependency injection, and explicit dependencies.

To keep code clean, Swaneveld pointed to three sources of feedback. The first is human review, acting as the human in the loop; the second is static analysis with PHPStan and PHPCS, providing deterministic feedback; the third is automated testing with code coverage and CRAP (Change Risk Anti-Patterns) scores, giving numerical feedback to pass back to the LLM. On the topic of review, he offered a clear warning:

“Don’t commit anything you don’t understand (or you won’t understand anything in a few months/years).”

Len Swaneveld, “Clean Code in the Age of AI”

The session From Drupal Content to AI Answers: Learnings from EPSY applied the very same principle to content. It detailed how a European Union agency developed a support chatbot for users of its platform. The case study highlighted that deploying a chatbot to production goes well beyond understanding RAG (Retrieval-Augmented Generation, the technique that retrieves relevant documents and passes them to the model as context), and that without well-structured source documents, responses remain unsatisfactory.

Structure also applies to people. In the talk Culture mapping the human side of AI, Timi Csontos defined culture as the collection of basic underlying assumptions shared by a group. She revisited the five stages of organizational culture evolution described by Frederic Laloux in “Reinventing Organizations”, matching each with an example:

• Impulsive (red): startups, characterized by concentrated power, authority, command-and-control, and fear.

• Conformist (amber): public administration, centered on hierarchy, formal processes, and stability.

• Achiever (orange): large multinational corporations, focused on goals, accountability, competition, merit, incentives, and innovation.

• Pluralistic (green): NGOs, driven by shared values, community, and fairness.

• Evolutionary (teal): Patagonia and Morning Star, guided by an evolutionary purpose and distributed decision-making.

Each stage preserves the strengths of preceding ones. According to Csontos, the change-culture gap is the distance between where an organization currently stands and where it wants to be: teams can either try to bridge it as quickly as possible or foster self-awareness, asking what they do best and how to improve, building on their strengths with empathy and understanding. Regarding AI adoption within teams, her advice was direct:

“Don’t split people based on experience, but give more personal attention to those who are lagging behind.”

Timi Csontos, “Culture mapping the human side of AI”

Mikaela Kindstedt and Sanna Kramsi, in Hidden Skills of Development, addressed making the invisible visible in team health, pointing to psychological safety as the cornerstone. One of the clearest points made was “Silence doesn’t equal agreement”: silence does not mean consent, which is why people must ask for clarification. The talk also covered clear guidelines and expectations, cognitive diversity, communication frameworks for healthy teams, resilience, and burnout prevention using an energy matrix inspired by the Eisenhower matrix.

Connecting the two talks, psychological safety is the foundation of the human review advocated by Swaneveld. A human in the loop who does not feel safe saying “I do not understand this code” ceases to act as an effective control, leaving the LLM without its most critical feedback loop.

Hooks, tests, forms, and CLI: where Drupal core is becoming more testable

Several conference sessions highlighted a core moving toward more organized, easier-to-verify code. We view this progression through Swaneveld’s lens: if clean code serves as context for the LLM, a more testable core transforms the baseline used by both developers and AI tools, making AI contributions more sustainable over time.

Fabian Bircher (Bircher on drupal.org) opened Refactor to #[Hook] by explaining his motivation for the session. A few months earlier, Dries mentioned that nobody was talking about the #[Hook] attribute at conferences, meaning the community was still largely unaware of it. Starting with Drupal 11.1, most hooks can be written as methods inside a class tagged with #[Hook], bringing cleaner code structure and dependency injection: two qualities that make hook logic far easier to unit test.

The main difference from procedural functions in a .module file is that dependencies are injected through the constructor. A minimal example using an arbitrary service illustrates the structure of an entity hook:

<?php

declare(strict_types=1);

namespace Drupal\my_module\Hook;

use Drupal\Core\Entity\EntityInterface;
use Drupal\Core\Hook\Attribute\Hook;
use Drupal\my_module\ArticleNotifier;

/**
 * Module hooks: classes in src/Hook are auto-discovered.
 */
final class MyModuleHooks {

  // The dependency is injected from the container: no calls to \Drupal::service().
  public function __construct(
    private readonly ArticleNotifier $notifier,
  ) {}

  // Replaces my_module_entity_insert() in the .module file.
  #[Hook('entity_insert')]
  public function entityInsert(EntityInterface $entity): void {
    if ($entity->getEntityTypeId() === 'node') {
      // In a unit test, simply pass a mock of ArticleNotifier.
      $this->notifier->notify($entity);
    }
  }

}

Bircher delivered three key takeaways: writing a hook this way is just as straightforward as the procedural approach, refactoring hooks out of .module files should not be intimidating, and adopting OOP hooks now keeps code compatible with upcoming Drupal releases. For maintainers of contrib or custom modules, his recommendation was clear: make the switch right away.

Francesco Placella’s (Plach) session, Inside the Pyramid - A path to faster, clearer Drupal testing, started with a straightforward observation: the Drupal test suite is slow in large part due to architectural choices. Core lacks formal guidelines detailing which test type to choose for specific scenarios, resulting in developers writing Kernel or Functional tests where a Unit test would be sufficient, faster, cheaper, and just as valid. He proposed adopting the test pyramid as an explicit, shared community strategy across core, contrib, and custom code.

• A broad foundation of Unit tests, fast and inexpensive to run.

• A leaner layer of Kernel tests, covering integration logic.

• A minimal number of Functional and FunctionalJavascript tests at the top, avoiding FunctionalJavascript tests to check isolated form elements.

• E2E coverage reserved strictly for business-critical workflows, and nothing else.

According to Placella, the entity system has long been the primary barrier to unit testing in Drupal. His proposal addresses this on two fronts: in core, making the entity system more accessible to unit tests; in contrib and custom code, abstracting entities behind custom interfaces so that business logic remains decoupled and testable in isolation. His library Deuteros provides test doubles for entities, particularly useful in legacy codebases where architectural refactoring is out of reach. Placella presented core maintainers with concrete recommendations on test strategy, tooling, and documentation, pursuing a clear goal: turning faster, more readable tests into the standard.

These two initiatives complement each other directly. A hook encapsulated in a class with injected dependencies, operating against an interface rather than a concrete entity, is exactly the type of code that belongs at the base of the testing pyramid.

On the front-end side, the session The joy and power of SDC, finally for form inputs showed that Single Directory Components (components bundling templates, styles, scripts, and schemas into one folder) can now be used for form elements as well. Support is still partial, but once complete, core will be able to eliminate tens of thousands of lines of PHP markup declarations currently used for form inputs. Defining that markup in PHP makes little sense to us, as forms should belong to the front-end domain, not the back end.

A joyful tour through the CLI now in Drupal Core introduced dr, or doctor: a native CLI tool in Drupal core powered by Symfony Console, designed as the successor to Drush. Drush has served Drupal well for years and stood out as a major strength of the CMS, but the new tool aims to standardize developer experience. Not all commands have been ported yet, and it will take time before dr becomes the sole CLI tool for managing Drupal. For now, Moshe recommends supporting both drush and dr commands in contrib modules: because they are thin wrappers around underlying services, the duplicated code is minimal.

For module maintainers, the actionable advice from these four sessions can be viewed side by side. The following table summarizes the key takeaways directly from the sessions:

Rikkert Steenbergen and Esmeralda Tijhoff, in When the roadmap is a battleground, shared how DICTU, a Dutch government agency, builds digital products for public administration using a shared Drupal platform. According to the speakers, DICTU represents the largest Drupal operation in the Netherlands, counting roughly 1,800 FTEs and over 450 million euros in turnover. Inspired by LocalGov Drupal, the model delivers Drupal as a service: a single codebase supporting multiple instances, a fixed annual fee, and DICTU retaining full ownership of the vision, roadmap, and backlog. Financial governance follows a cost-recovery model based on the principle of “public money, public code”.

The detail that stood out most involved Drupal Recipes, the packages that apply modules and configurations to a site in a single operation. At DICTU, recipes are applied and then discarded; to handle upgrade paths, the updated recipe is simply reapplied, an approach made possible because customers cannot modify site configurations directly. We see this as a compelling example of a platform sustained by clear constraints: the exact same principle behind guardrails, applied to configuration rather than model outputs.

MCP Client, Contribution Day, and why contributing matters

On Thursday, October 1, 2026, the General Contribution Day took place: a full day where the community collaborates on Drupal core, contrib modules, and documentation. Our Roberto Peruzzo attended, spending most of his time on MCP Client, a module he co-maintains with SparkFabrik’s backing².

The Model Context Protocol (MCP) is an open standard that normalizes how applications connect to external servers exposing tools and data to models. MCP Client enables Drupal to connect to external MCP servers and exposes their tools to both the Drupal AI module and ECA, serving both autonomous agents and configured platform workflows. The day’s progress in the issue queue includes:

• “Add MCP Server” page: resolved an issue where the page returned a 404 Page not found error (#3618561).

• Permissions: corrected support for a permission tier less privileged than full administrative access to manage MCP servers (#3618560).

• Sessions: opened a follow-up issue to handle resuming MCP sessions across separate HTTP requests (#3618562), building upon earlier work on persistent sessions (#3565713).

• OAuth: coordinated with Marcus Johansson on a plan to introduce OAuth authentication for MCP servers using the OpenID Connect module, enabling Drupal to connect to OAuth-protected MCP servers without requiring manual token renewals (#3618563).

In Roberto’s words, “contribution days are the opportunity to make targeted progress, meet the people behind the issue queues face to face, and invest time constructively in open source”.

SparkFabrik itself grew out of Drupal projects and has consistently championed open source: our work on MCP Client during Contribution Day is part of a broader commitment spanning more than a decade, traceable directly in the issue queues, such as our work on Drupal AI³. For these continued efforts, on May 14, 2026, the Drupal Association recognized SparkFabrik as the first Gold-tier Drupal Certified Partner in Italy⁴.

Contributing, however, goes beyond writing code. In the Rotterdam Driesnote, the Drupal project was described as healthy and backed by an active community. The acknowledged pain point is that many people still speak critically of Drupal, often because they are unfamiliar with it or base their opinion on versions from years past. The proposed initiative is a reward system, using contribution credits, for community advocacy, ranging from blog posts and social media updates to podcasts and presentations.

This form of contribution has often taken a back seat, yet we have always practiced it: sharing knowledge and best practices across the Drupal ecosystem through articles, talks, and social posts.

Sharing detailed write-ups of what we built and learned at DrupalCon is an active expression of that advocacy. Anyone interested in hearing the proposal directly from Dries can watch the full keynote recording on YouTube.

The recognition at the International Splash Awards aligns with this same effort, where the Luiss University project won in the Education category. It offers another channel to highlight what is being built with Drupal, which we analyzed to understand what it really rewards.

What we take home from Rotterdam and what to do right now

Every year, the European Drupal community gathers in person. For us, Rotterdam was valuable above all for the human connections: informal hallway conversations and technical exchanges with the developers behind the modules we implement for client projects. At the AI Dev Summit, we discussed guardrails and external tool integrations directly with the authors of that code. From the sessions, we gathered architectural approaches to apply across our work. During Contribution Day, we worked shoulder-to-shoulder with the community on issues shaping upcoming releases.

What can be adopted immediately? Decision models are available in Drupal AI 1.6.0-dev and can be deployed inside guardrails alongside regex checks, keyword filters, and moderation APIs. On MCP Client, work continues on session resumption between requests (#3618562) and OpenID Connect-based OAuth authentication (#3618563): these issues will determine how Drupal establishes controlled connections with external tooling.

To conclude, here is a practical recommendation. Before moving an AI feature to production in Drupal, or exposing an LLM or MCP server to site users, ensure these four controls are in place:

• Input: verify what data reaches the model and which filters intercept it before the API call is made.

• Output: confirm which guardrails validate the response before it reaches the end user or content repository.

• Permissions: verify which roles can trigger AI actions and configure MCP servers, which entities the AI is authorized to modify, and under what permissions tools execute.

• Authentication: establish how the site authenticates against external services, an area for MCP currently tied to ongoing issue development.

The next gathering for the Italian community is DrupalCamp Italy 2026, taking place on October 22, 2026, in Bologna. SparkFabrik is among the organizers. We look forward to meeting you there to continue the conversation in person.

If you are exploring how to integrate AI agents into an upcoming Drupal project, contact the SparkFabrik team.

Notes and sources

Note e fonti