An Airflow role can limit what a person sees in the UI and API. It does not turn a DAG file into a harmless configuration document. Airflow executes DAG author code in the DAG File Processor, the Triggerer, and workers. The security model is therefore shaped by the deployment context around each component, not only by the RBAC role attached to a user.
Code runs where Airflow runs it
Airflow's security model states that DAG file code executes in several components and can potentially access credentials the DAG code uses for external systems. In Airflow 3, worker task code communicates with the API server through the Execution API and does not receive metadata database credentials. That is a meaningful improvement for workers.
The Dag File Processor and Triggerer have a different boundary. Airflow uses software guards to prevent accidental direct database access from author code, but those processes run as the same Unix user as their parent processes, which do have database credentials. A malicious DAG author may be able to retrieve credentials from the parent process and obtain direct database access. The documentation describes this as an isolation limitation, not a supported permission model.
This means a UI role such as a limited DAG editor can still represent a large privilege if the same person can place code into a location that Airflow parses. The role governs UI actions. The repository, file mount, package environment, and worker identity govern what the code can do once Airflow executes it.
Treat the DAG repository as privileged code
The percentage of users who can merge a DAG change should be small. A code review should inspect imports, package installation, subprocess calls, file reads, network destinations, and access to connections or secrets. It should also check how the DAG is discovered. A shared writable volume or a permissive branch that feeds the DAG processor can bypass the intended review path.
Connections and variables need the same scrutiny. A DAG that can read every connection can move data across systems its author was never intended to reach. Scope credentials per workload where the deployment permits it. Avoid placing unrestricted administrative tokens in Airflow merely because the scheduler is a convenient secret store.
Isolate the components you can isolate
A stronger deployment separates the scheduler and API server from DAG files where possible, runs the DAG processor under a dedicated identity, and keeps workers on dedicated infrastructure. The deployment manager should decide whether different teams need separate Airflow instances rather than assuming RBAC provides process isolation. Airflow's own documentation notes that perfect isolation between DAG authors is not yet achieved.
The API server should not execute DAG author code. The worker should not receive database credentials. The triggerer and processor should run with only the filesystem access and network reachability they need. These are deployment controls, not settings that a DAG author should be able to change from inside a task.
Audit the effective path
Map which identities can write DAG files, which paths Airflow scans, which process parses them, and which credentials that process can obtain. Then compare that map with the UI roles. A user may be limited in the UI but powerful through a repository. Another user may be a deployment manager with no UI role at all.
Review recently created DAGs for external commands, package installation, direct database libraries, and unusual secret references. Check the Triggerer and processor parent environments for mounted credentials. Alert on changes to DAG mounts and startup configuration. These signals point to a change in the effective code boundary.
Airflow gives teams a useful orchestration control plane. The security decision is whether the organization treats DAG authoring as code deployment. When that answer is explicit, RBAC becomes one layer in a larger model that includes repository review, workload identity, and component isolation.