Before a Drupal AI Demo Goes Live, Rehearse the Permissions

Illustrated infographic summarizing: Drupal AI Demos Need a Permissions Rehearsal Before Launch

By Greg Nowak. Updated 18 August 2026.

A convincing Drupal AI demo should make complicated work look simple. That simplicity can be deceptive. Behind one chat box may sit workflow endpoints, privileged tools, uploaded files, third-party models, approval gates, and actions that cost money or change content.

That is why the final rehearsal should test more than prompts and presentation timing. Before an agency puts Drupal AI in front of a client, the team should confirm who can start each action, what happens after a workflow loops, whether sessions remain separate, and how quickly the feature can be stopped or rolled back.

This is not a substitute for a full security review. It is a focused operational check designed to catch the failures most likely to undermine a demonstration or pilot.

What the July 2026 Drupal advisories changed

Three contributed-project advisories published on 1 July make the risk concrete.

SA-CONTRIB-2026-067 reports that FlowDrop did not sufficiently enforce permissions on some 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 added a separate Execute session workflow requirement for driving a session.

SA-CONTRIB-2026-068 concerns human approval. FlowDrop did not adequately re-evaluate an approval gate when a workflow iterated more than once. The lesson is broader than one module: approving the first pass does not automatically authorize every retry, branch, or revised action that follows.

SA-CONTRIB-2026-065 covers insufficient validation of image uploads in the Drupal Canvas AI submodule. Files were written to Drupal’s temporary directory and could, in some cases, lead to cross-site scripting. An upload field that feels incidental to the demo therefore deserves the same attention as any other public or authenticated file endpoint.

The rehearsal matrix

Area	Test	Stop the launch if
Roles and endpoints	Attempt every demo action as the demo role, editor, administrator, ordinary authenticated user, and anonymous visitor where applicable.	A disallowed role can execute or alter a workflow.
Approval loops	Force a retry, revision, branch, and second sensitive action after the first approval.	Approval silently carries into an action the user did not review.
Session boundaries	Run separate sessions in different accounts and browsers, then try direct session URLs and requests.	One user can read, message, or control another user’s session.
Uploads	Try allowed images, renamed files, mismatched extensions and MIME types, oversized files, and filenames containing unusual characters.	An unexpected file is accepted, executed, or rendered unsafely.
Models and tools	Confirm provider keys, budgets, rate limits, and permissions for every connected tool.	The demo role can create unbounded spend or unintended external actions.
Recovery	Practise disabling the feature and restoring the known-good code and configuration.	The team cannot explain or perform rollback confidently.

A client demo is ready only when both the visible workflow and its less-visible failure paths have been rehearsed.

Start with versions, not assumptions

Record the installed versions of FlowDrop, Canvas, the Drupal AI modules, and any connector or tool modules. The two FlowDrop advisories affect versions earlier than 1.6.0. The Canvas advisory lists patched releases for several supported branches: 1.4.2, 1.5.2, 1.6.1, and 1.7.1. Treat these as minimum fixes from the advisories, not a reason to downgrade a newer supported installation.

For a Composer-managed project, inspect the proposed change before applying it:

composer audit
composer outdated "drupal/*"
composer update drupal/flowdrop drupal/canvas --with-all-dependencies --dry-run

After taking an appropriate database backup, apply the tested update in a non-production environment. Drupal’s current Composer guidance finishes the process with database updates, a cache rebuild, and configuration review:

composer update drupal/flowdrop drupal/canvas --with-all-dependencies
drush updatedb
drush cache:rebuild
drush config:export --diff

Commit the resulting composer.lock and configuration changes so the same build can be deployed. If only one affected module is installed, update only that package. Never add Canvas or FlowDrop merely to run these commands.

Test permission as behaviour, not configuration

A permission screen shows intended policy; it does not prove the running system enforces that policy at every route. Build a small role-to-action map covering workflow creation, editing, execution, session viewing, approval, uploads, and administration. Remove privileges from the account used during the client meeting, then verify that denied actions fail on the server—not merely that their buttons disappear.

Use at least two accounts when checking session isolation. Start a workflow as one person, obtain or observe its session identifier, and attempt to view or drive it as the other. Repeat the test after a browser refresh and after the workflow has paused for approval. This exposes assumptions that a single-user walkthrough will never reveal.

Make the human approval genuinely human

Do not test an approval gate only on the happy path. Ask the workflow to revise its answer, retry a failed tool call, return to an earlier step, and branch toward a second consequential action. At each point, establish what the approver can see: the proposed action, affected content or system, relevant input, and likely side effects.

If the workflow changes meaningfully after approval, it should return for review before acting. The important question is not whether the interface displays an approval button. It is whether approval remains scoped to the action the person actually understood.

Define a clear go/no-go decision

The demo can proceed when the installed versions are supported and patched, the demo role has only the permissions it needs, repeated approvals behave predictably, sessions remain isolated, uploads are constrained, and logging identifies who initiated consequential actions. The team should also know how to disable tools, revoke provider credentials, and restore the previous build.

If one of those answers is uncertain, narrow the demonstration. Use non-sensitive content, remove uploads, disconnect write-capable tools, cap provider usage, or show a recorded path while the underlying issue is resolved. A smaller controlled demo is more persuasive than an ambitious one the team cannot safely explain.

A stronger demo starts before the meeting

For business owners, this rehearsal protects the credibility of the investment. For operations leads, it establishes ownership and recovery steps. For agencies, it turns security advisories into a practical launch discipline the client can understand.

If you need an independent pair of eyes, Greg can help review the module inventory, permission model, workflow behaviour, update plan, and rollback route before your Drupal AI demonstration reaches stakeholders. Start a conversation about your Drupal AI readiness review.

Related on GrN.dk

Need help with this kind of work?

Discuss a Drupal AI readiness review Get in touch with Greg.

Sources

Last modified

2026-08-18