Per the Airflow security model, worker task code in Airflow 3 does not receive database credentials and cannot access the metadata database directly, since it communicates through the Execution API. The Dag File Processor and Triggerer are different: DAG author code there may still reach the database.
What the docs state
The Airflow security model page describes the trust boundaries. Workers communicate with the API server exclusively through the Execution API, and do not receive database credentials. The scheduler, the API server, the Dag File Processor and the Triggerer have direct database access. The doc's diagram marks the Dag File Processor and Triggerer as having an in-process path that bypasses JWT authentication.
For those two, the docs say Airflow implements software guards that prevent accidental direct database access from DAG author code. But because DAG parsing and trigger execution run as the same Unix user as their parent processes, which hold database credentials, a deliberately malicious DAG author can potentially retrieve credentials from the parent process and gain access.
What this does and does not give you
| Component | Database access | Implication |
|---|---|---|
| Worker task code | Through Execution API only | Smaller exposure for task code |
| Dag File Processor | Potentially direct | DAG file code is trusted code |
| Triggerer | Potentially direct | Trigger code is trusted code |
The docs are also clear that a task with a valid token is not limited per DAG: it can call state-changing Execution API endpoints, such as triggering or clearing runs and reading or writing variables, connections and XComs, for any DAG in the installation. The ti:self token scope restricts cross-task state changes only, and is not a per DAG access control.
So the improvement is real but narrow. It removes direct database credentials from workers. It does not make DAG authors independent from each other.
The consequence for teams
The same page says that, until multi-team isolation matures, you should assume that all DAG authors have access to all DAGs and shared resources, and can modify their state regardless of team assignment. The multi-team feature is described as experimental and a work in progress at the task level.
That has direct planning value:
- Separate deployments for separate trust levels. If two groups should not see each other's connections, give them separate Airflow installations rather than relying on UI roles.
- Review DAG code like production code. Parse time code runs in components with database access.
- Scope connections. Each connection is reachable by tasks across the installation, so give credentials only the access a pipeline needs.
- Limit who can write DAG files. See who can run code in Airflow: DAG authors and trust.
What to ask when upgrading
If you are moving from Airflow 2, look for code that reads the metadata database from a task, since that pattern no longer works for workers. Check the release notes for your version and test your DAGs in a non-production environment.
Safeguard's dependency scanning and reachability analysis can help you see which vulnerable packages in your Airflow image are actually used. A free scan is at gold.safeguard.sh/scan.
Quick check
Do all Airflow 3 components lack database access?
No. Workers go through the Execution API, but the scheduler, API server, Dag File Processor and Triggerer have database access.
Can one team's tasks read another team's connections?
The docs say tasks share the same Execution API, connections and variables in multi-team mode, so assume they can, and separate installations where it matters.
Sources
- Airflow security model, Apache Airflow documentation, fetched 19 October 2026.
Last reviewed: 19 October 2026.
