Be more explicit about how consumer flows are executed.

Warnings around potential security risks in using flows owned by other users.

alerts/alerts.md

@@ -13,6 +13,15 @@ In brief, _dispatchers_ send _events_, which are then processed by _consumers_.
 
 This page will show how to create and configure alerts, using as an example an alert which sends notifications whenever an admin-level account logs in, for instance when `root` logs in via ssh or `admin` logs in to Gravwell.
 
+```{important}
+There are a few important things to keep in mind regarding ownership & permissions when defining alerts:
+
+* An alert can use scheduled searches owned by other users as dispatchers, provided the alert owner has permission to view the results of those searches. Note that if the scheduled search owner changes permissions or deletes the search, the alert may no longer work properly.
+* An alert can use flows owned by other users as consumers, provided the alert owner has permission to view the flow. This has a variety of potential complications detailed below.
+  * If the flow uses resources, macros, secrets, or other items owned by the flow owner but not shared with the alert owner, the flow may not execute properly when triggered by the alert.
+  * The flow owner has the ability to modify the flow without notifying the alert owner; this means the alert may stop behaving properly, or in the case of a malicious flow owner, the flow could be used to e.g. leak the contents of the alert events.
+```
+
 ## Creating an Alert
 
 Alerts are defined in the Alerts page, found under the Automation sub-menu. Clicking "Create an alert" on this page will open a wizard to define a new alert:
@@ -144,6 +153,10 @@ When we click the Debug button in the Flows editor, we should shortly receive an
 
 ![](debug-email.png)
 
+```{note}
+When a flow is run in response to an actual alert trigger, the flow's results fields (payloads, last run time, etc.) are *not* updated, both to avoid leaking any sensitive material and because a single alert activation may run the same flow dozens of times, making updating the results less useful.
+```
+
 ### Adding a Flow Consumer
 
 Once the flow is defined, we can add it to our alert either through the Alert editor, or from the Settings tab of the Flow editor:

automation.md

@@ -3,11 +3,11 @@
 Gravwell provides several utilities to enable automated operations. At the most basic level, users can schedule searches to be executed at specific times, for example every morning at 1:00. They can also schedule flows and scripts, which can execute multiple searches, sift and parse search results, and send notifications via email or HTTP. Flows are designed using a drag-and-drop graphical interface and are generally preferred over scripts, which should be reserved for legacy situations or very particular use cases that flows cannot cover.
 
 ```{attention}
-An automation (Flow, Scheduled Search, or Script) runs as the user who owns the automation. 
+An automation (Flow, Scheduled Search, or Script) runs as the user who owns the automation, except when triggered by an alert.
 
-Granting write access to automations (currently Flows and Scheduled Searches) has important implications.
+Granting write access to an automation has important implications. When you grant a group write access to a Flow or Scheduled Search, you are granting them the ability to modify and execute it as **your user**. Consider using a machine user with the least privileges necessary as the owner of shared automations.
 
-When you grant a group write access to a Flow or Scheduled Search, you are granting them the ability to modify and execute it as **your user**. Consider using a machine user with the least privileges necessary as the owner of shared automations. 
+When a flow is run in response to an [alert](/alerts/alerts), it runs as the owner of the alert. This also has implications: the alert owner is executing code defined by the flow owner. Don't use flows owned by untrusted users as consumers on your alerts.
 ```
 
 ## Gravwell Automation