By Greg Nowak. Last updated 2026-09-18.
Updated 18 September 2026.
A polished Drupal AI demo can make a complicated workflow look effortless. Behind the chat box, however, there may be privileged endpoints, uploaded files, third-party models, approval gates, and tools capable of changing content or spending money.
The final rehearsal should therefore test more than prompts and presentation timing. It should establish who can execute each action, whether approvals survive loops safely, how sessions are separated, and how the team will stop the feature if something behaves unexpectedly.
This is not a replacement for penetration testing or a full security review. It is a practical launch check for business owners, operations leads, and agency teams that need to decide whether a demonstration is controlled enough to put in front of stakeholders.
Why permissions deserve their own rehearsal
Three Drupal security advisories published on 1 July 2026 illustrate why a successful happy-path test is not enough.
SA-CONTRIB-2026-067 reports that FlowDrop versions before 1.6.0 did not sufficiently enforce permissions on certain endpoints. A user with the broad View any session permission could potentially trigger workflow execution, incur LLM costs, cause tool side effects, or send messages into another user’s session. FlowDrop 1.6.0 introduced a separate Execute session workflow requirement for driving a session.
SA-CONTRIB-2026-068 concerns approval loops. Before version 1.6.0, FlowDrop did not sufficiently re-evaluate a human approval gate when a workflow iterated more than once. The operational lesson is important: approval of one proposed action should not silently authorize a revised action, retry, or later branch.
SA-CONTRIB-2026-065 covers insufficient validation of image uploads in the Drupal Canvas AI submodule. Files written to Drupal’s temporary directory could, in some cases, lead to cross-site scripting. An upload control that appears incidental to the presentation must be treated as a real application endpoint.
Use a go/no-go rehearsal matrix
| Area | Rehearsal | Do not launch if |
|---|---|---|
| Roles | Run each action as the demo user, editor, administrator, ordinary authenticated user, and anonymous visitor where relevant. | A disallowed role can execute or alter a workflow. |
| Approval loops | Force a retry, revision, second tool call, and branch after approval. | The original approval carries over without another meaningful review. |
| Sessions | Use two accounts and separate browsers; test direct session URLs before and after an approval pause. | One account can read, message, or control another account’s session. |
| Uploads | Try permitted files plus renamed, oversized, malformed, and MIME-mismatched files. | An unexpected file is accepted or rendered unsafely. |
| Models and tools | Confirm credentials, spending limits, rate limits, and write permissions for every integration. | The demo can create uncontrolled cost or external changes. |
| Recovery | Practise disabling the workflow, revoking credentials, and restoring the known-good build. | Rollback depends on guesswork during the meeting. |
Patch first, then test behaviour
Record the installed versions of FlowDrop, Canvas, Drupal AI components, and every connector used by the demonstration. Both FlowDrop advisories affect versions earlier than 1.6.0. The Canvas advisory identifies patched releases for four branches: 1.4.2, 1.5.2, 1.6.1, and 1.7.1. Those are advisory-specific minimums, not instructions to downgrade a newer supported release.
For a Composer-managed site, inspect the current installation and proposed changes in a development or staging environment:
composer show drupal/flowdrop
composer show drupal/canvas
composer audit
composer outdated "drupal/*"
composer update drupal/flowdrop drupal/canvas --with-all-dependencies --dry-runOnly include packages that the project actually uses. After taking appropriate backups, apply and test the update outside production:
composer update drupal/flowdrop drupal/canvas --with-all-dependencies
drush updatedb
drush cache:rebuild
drush config:export --diffReview and commit the resulting lock-file and configuration changes. Promote that tested build through the normal deployment process; production should generally receive the committed dependencies with composer install --no-dev, rather than resolving fresh versions with composer update.
Test access as behaviour, not a permission-screen screenshot
Create a small role-to-action map covering workflow creation, editing, execution, session viewing, approval, uploads, and administration. Give the meeting account only the permissions needed for the demonstration. Then verify that prohibited requests fail on the server. Hiding a button is useful interface design, but it is not proof of access control.
Use at least two accounts for session testing. Start a workflow as one person, observe its session identifier, and attempt to view or drive it as the other. Repeat after refreshing the browser and while the workflow is paused. This catches boundary failures that a single administrator account will conceal.
Make approval specific and understandable
An approver should be able to see what action is proposed, which content or external system it affects, the important input, and the likely side effects. If any of those elements change after a retry or revision, send the workflow back for approval.
Also rehearse refusal. Confirm that rejecting or abandoning an action does not leave a queued tool call, half-finished content change, or workflow that another user can resume unexpectedly. The goal is not simply to display an approval button; it is to preserve the meaning of the person’s decision.
Prefer a smaller demo to an unexplained risk
Proceed when patched versions are installed, permissions are minimal, sessions remain separate, repeated approvals behave predictably, uploads are constrained, and logs identify who initiated consequential actions. Assign one person to watch provider usage and another to own the stop decision.
If an answer remains uncertain, reduce the scope: use non-sensitive content, remove uploads, disconnect write-capable tools, cap provider usage, or demonstrate a recorded path while the issue is resolved. A controlled demonstration builds more confidence than an ambitious one the team cannot safely explain.
If you would value an independent review, Greg can help examine the module inventory, permission model, workflow behaviour, deployment plan, and rollback route before the demonstration reaches clients or internal stakeholders. Talk with Greg about a Drupal AI readiness review.
Related on GrN.dk
- AI disclosure rules belong in your CMS, not a spreadsheet
- Before Your Support Bot Learns the Help Center, Test Whether It Can Forget
- Before Your Website AI Bot Goes Live: Prompt-Injection Controls for Chat and Lead Capture
Need help with this kind of work?
Discuss your Drupal AI readiness review Get in touch with Greg.
