Reads run freely. Every tool that changes the site is behind a gate, by category, so you can let an agent create content without also letting it run raw SQL.

Where the gates live

The gates are flags in droost's own settings file, settings.droost.php, beside settings.php. They are never in exported configuration, so an armed gate cannot travel to another site with a config import.

On a CLI call, ordinary write categories are enabled unless explicitly disabled, while PHP evaluation and raw SQL writes stay off until explicitly enabled. An agent on a local site can already run PHP and SQL through drush, so those two are a switch for you, not a default.

The gates

Gate Unlocks
allow_destructive fallback for ordinary write categories with no explicit value; excludes PHP evaluation and raw SQL writes
allow_scaffold droost_structure_create
allow_entity_write entity create, update and delete, droost_canvas_tree_set, droost_generate
allow_db_write droost_db_create, droost_db_update, droost_db_delete
allow_config_write droost_config_set, droost_views_compose, droost_views_alter, droost_canvas_component_toggle, droost_canvas_variant_tree_set, droost_config_import_one
allow_module_ops droost_module_install, droost_module_uninstall, droost_cron_run, droost_deploy_hook_reset
allow_eval droost_eval (arbitrary PHP)

An explicit category value takes precedence over allow_destructive. Inspect the resolved gate states rather than assuming the master overrides every flag.

Arming a gate

bash
drush droost:gate                              # every gate and its state
drush droost:gate allow_eval on                # turn on PHP evaluation, locally
drush droost:gate allow_destructive off        # disable otherwise-unset ordinary write categories

drush droost:gate <gate> on requires an interactive terminal. The intended workflow is for the agent to request a change and for the operator to run the command. This terminal check does not isolate an agent that already has full shell access or permission to edit the settings file. A gate is read on every call, so a change takes effect at once. /admin/config/development/droost shows every gate's state.

Over the web

Over the web, the development default does not apply: a write runs only when settings.droost.php arms its gate explicitly, and a gate nobody set is off. The build and developer tools refuse every web request, armed or not. See Over MCP, for editors.

A refusal is the gate working

When a write refuses, the message names the gate. Arm it if you mean it, or leave it off.

Safety notes

  • Secret redaction is a best effort. droost_config_get and droost_entity_load hide values whose key looks secret (password, token, key, credential, salt, oauth…). It is a check on key names, not on content.
  • SQL is split by intent. droost_db_read runs reads; each write tool runs one statement of its own verb, and refuses an UPDATE or DELETE with no WHERE. For reads that are read-only in the database itself, add a droost_readonly connection backed by a SELECT-only user: droost_db_read uses it when it exists.