By Greg Nowak. Last updated 2026-07-07.
Drupal AI has moved past the lab-demo stage. Drupal’s AI overview presents it as an enterprise-grade open source AI solution, with AI-human collaboration, governance, model flexibility, and demos for content, accessibility, and marketing work. That is a good sales story. It also means agencies need to treat client demos with more discipline than a polished prompt walkthrough.
The July 1, 2026 contributed-module advisories make the point clearly. A Drupal AI demo can involve live permissions, workflow execution, uploads, chat sessions, and connectors to paid LLM services or external tools. So the launch question is not only: does the AI feature work? It is also: what happens when the wrong role calls the endpoint, an approval loop repeats, a file upload is unexpected, or one user’s session touches another?
That is the job of a permissions rehearsal. It is a compact readiness check before the demo goes in front of a client, sponsor, or internal stakeholder. It should not turn a pilot into a six-week audit. It should make the risky parts visible early, while there is still time to patch, limit, disable, or explain them.
What the July advisories show
SA-CONTRIB-2026-068 covers FlowDrop, a module used to test and run AI-driven workflows interactively through chat. The advisory says a human-in-the-loop approval gate was not sufficiently re-evaluated when a workflow iterated more than once. In practical terms, approving the happy path once is not enough. If the workflow can retry, revise, branch, or loop, approval needs to be tested across those later passes too.
SA-CONTRIB-2026-067, also for FlowDrop, points to insufficient permission enforcement on certain endpoints. The advisory describes possible workflow execution, LLM spend, tool side effects, and messages being sent into other users’ sessions. It also notes that driving a session now additionally requires the Execute session workflow permission. For an agency demo, this is the uncomfortable part: the chat box may look simple, while the action surface behind it is powerful.
SA-CONTRIB-2026-065 covers Drupal Canvas. Its Canvas AI submodule allows image uploads through a custom API for AI web chat. The advisory says uploads were insufficiently validated before being written to Drupal’s temporary directory and could, in some cases, lead to cross-site scripting. That moves the review beyond prompt quality. If the demo accepts files, then validation, temporary storage, rendering, naming, and cleanup are all part of launch readiness.
The issue is not limited to one module
The Common Weakness Enumeration entry for CWE-862: Missing Authorization describes the broader pattern: software lets an actor reach a resource or perform an action without the right authorization check. Its mitigation guidance matters for Drupal AI because it separates ordinary access from business-logic access. A user may be logged in. A route may respond. A session may be valid. None of that proves the user should be able to execute a workflow, drive a session, approve an iteration, or affect someone else’s chat.
The CWE guidance also emphasizes server-side checks and role mapping. In Drupal terms, the rehearsal should test anonymous, authenticated, editor, administrator, demo-only, and workflow-author roles against the real routes and actions used in the demo. Looking at the visible UI is useful, but it is not enough. The server has to reject requests the interface was never meant to expose.
The upload advisory lines up with CWE-434: Unrestricted Upload of File with Dangerous Type. CWE-434 recommends strict allowlisting, unique generated filenames, limited extensions, server-side validation, and caution around MIME type or filename checks. In AI chat, uploads feel natural: attach an image, ask a question, keep working. The security model still needs to be explicit and boring.
| Rehearsal area | Why it matters | What to test | Go/no-go question |
|---|---|---|---|
| Workflow permissions | FlowDrop advisories describe endpoint permission gaps and a new execution permission. | Run workflow actions as each demo role, including direct endpoint requests where appropriate. | Can unauthorized roles execute, alter, or drive sessions? |
| Approval loops | One FlowDrop advisory covers approval not being re-checked when a workflow iterates. | Force retries, branches, revisions, and repeated sensitive actions after approval. | Is approval checked at every meaningful iteration? |
| LLM spend and tool actions | Workflow execution may trigger LLM costs or external side effects. | Confirm demo budgets, rate limits, tool permissions, and logs. | Are cost and external actions bounded? |
| Chat session boundaries | The advisory notes messages could affect other users’ sessions. | Use multiple users, roles, and browsers to test session isolation. | Can one user pollute or control another user’s session? |
| AI file uploads | Canvas AI upload validation maps to the risks described in CWE-434. | Check allowed types, extensions, MIME handling, temporary storage, and browser rendering. | Are unexpected files rejected or safely transformed? |
| Patch and rollback | The advisories point to patched versions. | Confirm Composer updates, config export, cache clear, smoke tests, and rollback steps. | Can the team patch or revert without improvising? |
What the review should cover
Start with inventory. Which contributed modules are involved? Which submodules are enabled? Which versions are installed? Which routes, permissions, queues, temporary files, and third-party services does the demo touch? The July advisories include version-specific fixes, so Composer state is part of the readiness picture. FlowDrop users are directed to 1.6.0. Canvas users are directed to patched releases across supported minor branches.
Then test roles against actions. Map Drupal roles to the actual demo behavior: create workflow, edit workflow, administer workflow, view sessions, execute session workflow, upload files, and approve changes. Remove one permission at a time and verify the result. The aim is not a nicer error message. The aim is a server-side denial that stops the action.
The human-in-the-loop path deserves a scenario, not a checkbox. Run the workflow once. Ask it to iterate. Change the prompt. Retry a step. Add a branch. Then check whether the approval gate still appears before the workflow returns to a sensitive action. Drupal’s AI positioning rightly talks about humans directing, reviewing, and approving AI-driven changes. The rehearsal checks whether that control survives realistic workflow behavior.
Upload testing should be just as plain. If the AI chat accepts images, try valid images, renamed files, multiple extensions, unexpected MIME types, oversized files, and files that should never be rendered back into the browser. Check whether files land in temporary storage, whether names are generated rather than user-controlled, and whether cleanup is predictable. This is not exotic security work. It is basic operational hygiene for an upload-enabled client demo.
Logs and rollback come last, but they are not optional. Because the FlowDrop advisory mentions LLM spend and tool side effects, the team should be able to answer who ran a workflow, under which role, which session was affected, whether external tools ran, and whether spend was triggered. Rollback should be written down before the meeting: package versions, configuration exports, cache clears, smoke tests, and a clear decision point for disabling the demo if behavior is not understood.
The commercial point
This is not an argument against Drupal AI. It is an argument for presenting it professionally. Drupal’s AI story depends on control, governance, flexibility, and faster delivery. A permissions rehearsal supports that story because it shows the client that the agency understands both the opportunity and the operating boundary.
For GrN.dk, the natural service offer is a focused Drupal AI readiness review before a demo goes live: module inventory, Composer updates, role and endpoint testing, upload validation, human-in-the-loop scenario testing, log review, and rollback planning. It is a small engagement with a clear business result. The client sees a stronger demo. The agency avoids avoidable surprises. The AI feature enters the room as a governed CMS capability, not a fragile experiment.
Related on GrN.dk
- OpenAI's Guardrails and Run State Make Internal Agent Rollouts a Paid Approval-and-Audit Job
- WordPress headless menus need an exposure check before launch
- Agent-ready APIs need a contract audit before MCP rollout
Need help with this kind of work?
Book a Drupal AI readiness review Get in touch with Greg.