In Apache Airflow, Dag authors can run arbitrary code, and Airflow does not check or sandbox it. The security model treats them as trusted. So the practical answer is that whoever can merge a Dag file can run code on your workers, so protect your Dag repository like production code.
The roles in Airflow's security model
The Airflow documentation describes several roles:
- Deployment Managers install and configure Airflow and control its permissions. The docs say they can potentially delete the entire installation and have access to all credentials.
- Dag authors write and change Dag files. The docs say that code is neither verified, checked nor sand-boxed by Airflow. They can also see and modify every Dag, with no per-Dag restriction.
- Authenticated UI users have power depending on their role, from admins down to read only viewers. A connection configuration role can write credentials but not read them, and Airflow 3 masks sensitive values at the API level.
- Unauthenticated users are not supported by default, apart from the health and login endpoints.
Where Dag code runs
| Component | Who controls the code | Note from the docs |
|---|---|---|
| Local executor | Dag authors | Runs on the scheduler machine and can affect the whole installation |
| Celery workers | Dag authors | Tasks on the same worker can influence each other unless queues are separated |
| Kubernetes pods | Dag authors | Each task gets its own pod, so tasks are isolated |
| Triggerer | Dag authors | One shared instance by default |
| Dag File Processor | Dag authors | Parses Dag files and has direct metadata database access |
| Scheduler and API server | Should not run Dag author code | The docs say no Dag author code should ever run there |
Limits worth knowing
Workers use the Execution API and do not receive database credentials. The docs say the Dag File Processor and Triggerer have software guards against accidental database access, but these do not stop a malicious Dag author, since they run as the same Unix user. Execution API tokens do not carry per Dag authorization, so a running task can reach state changing endpoints for any Dag. Multi team mode is described as experimental and still shares signing keys, connections and variables.
What to do with this
- Gate the Dag repository. Require pull request review and branch protection for the branch Airflow reads.
- Keep the author group small and review membership regularly.
- Isolate where you can. Per task pods give isolation that a shared Celery worker does not.
- Do not rely on the UI roles to contain a Dag author. They are a different trust level.
- Separate environments. Do not let a team with a test deployment share secrets with production.
- Scan Dag dependencies, since Dag code imports libraries from your image. See Airflow providers and updates.
Quick check
Is Airflow a sandbox for untrusted Dag code?
No. The docs say Dag code is not verified, checked or sandboxed. Use Dag authors you trust.
Does read only UI access protect against a Dag author?
No. UI roles are a separate matter. A Dag author's power comes from code that executes in Airflow components.
Safeguard policies can gate changes to dependency files in pull requests, which helps when Dag authors add libraries. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
