What the Apache Airflow security model means for DAG authors
In a team where many people can merge DAG code into a shared repository, every merge is a code execution grant. Airflow's security model states that it does not verify, check or sandbox DAG code, so DAG authors can effectively run arbitrary code on workers, the DAG File Processor and the Triggerer, and can change the state of any task instance. This is a design statement in the project's own security model, not a defect to be patched later, and the rest of this page works through what follows from it. Apache Airflow is released under the Apache License 2.0 and runs in infrastructure you operate, so the review, repository and deployment controls that limit this exposure are your responsibility, not the project's or DeployOpen's default.
The practical question is who can merge, and what they can reach once their code runs. Start by listing everyone with write access to the DAG repository, the DAG bundle or the deployment pipeline that syncs DAG files to the scheduler and workers, including service accounts and CI jobs. Then confirm which component each code path runs in, because the DAG File Processor and Triggerer carry only software guards that do not stop a deliberately malicious author. Treat any author as able to read environment values and print them into task logs, so confirm who can view logs in your deployment and whether those logs leave the cluster. Confirm these details against the Airflow security model for your exact release before you set the policy.
What Airflow does not sandbox for DAG authors
Airflow treats DAG code as trusted. The cards below list the components where a DAG author's code runs without isolation from the rest of the deployment, and the controls the operator must put in place around each one. Read them together: the review, repository and deployment controls are what stand in for a sandbox that Airflow does not provide.
Arbitrary code on workers
The security model says Airflow does not verify, check or sandbox DAG code, so a DAG author can effectively run arbitrary code on workers. Workers do not receive database credentials and cannot reach the metadata database directly, but code running inside a task can still call any network service the worker can reach. Check which secrets, cloud roles and network paths each worker can use, and treat every task as code you have already approved.
Code in the DAG File Processor
The DAG File Processor parses DAG files to build the schedule, so a DAG author's module-level code runs there as soon as the file is parsed. The model says the software guards on this component do not stop a deliberately malicious author. Run the DAG File Processor as a separate component with the narrowest credentials and network access you can give it, and watch its resource use for parsing that never finishes.
Code in the Triggerer
Deferrable operators run their waiting logic in the Triggerer, which can execute code written by a DAG author. The security model states that the Triggerer has only software guards against a deliberately malicious author. Decide which Triggerer hosts can reach internal APIs, and keep it on a network segment and credential set separate from the systems that hold sensitive data.
Changing any task instance state
The model says DAG authors can modify the state of any task instance, including tasks in DAGs they did not write. A single merged change can mark runs as succeeded, clear failures, or re-trigger work that moves money or data. Limit who can merge to shared DAG folders, and review changes that touch shared operators or task dependencies with the same care as production code.
Sensitive values in task logs
DAG code can print environment variables and other sensitive values into task logs, and Airflow's masking works on known names rather than on the content of a DAG author's output. The model recommends restricting access to task logs. Decide who may read logs for each DAG, scan new DAGs for code that prints the environment, and keep log retention aligned with the sensitivity of the data a task handles.
Access to DAGs owned by other teams
Because any DAG author can affect any task instance, a shared Airflow instance gives one team's code the same reach as another team's. Access to the DAG folder, the repository and the deployment pipeline therefore sets the real boundary between teams. Map which repositories can deploy to the shared instance, and consider separate instances when a team's pipelines must stay isolated.
Review controls that follow from the trust model
The sequence turns the security model's guidance into controls that run before any DAG reaches a worker: review, static analysis, pull request approval, deployment gating and log access limits. Each step has a check that shows it held.
Confirm DAG code is the only path to production
Start by mapping every route that can put Python into the DAG folder, including direct pushes, CI jobs, object storage syncs and manual copies to the DAG File Processor's storage. Because Airflow does not verify or sandbox DAG code, anything that reaches that folder can run on workers, the DAG File Processor and the Triggerer. Write the approved path down as a diagram. The check is a list of paths that all end at the same protected branch or artifact, with no other writer to the DAG location.
Require pull requests with branch protection
Configure the repository so the protected branch cannot be changed without a pull request. Disable force pushes, block direct commits to the release branch and require the status checks from the pipeline to pass before merge. Apply the same rules to administrators, since an admin bypass is a path around review. The check is a test merge attempt from an account with write access that is refused until the required approvals and checks are in place, with the attempt recorded in the repository audit trail.
Run static analysis on every change
Add an automated stage that scans each DAG change before it can merge. Include linting and the Airflow upgrade rules from Ruff (AIR301 and AIR302 are the rule families the Airflow 3 upgrade guide names), plus security-focused static analysis that flags shell execution, network calls, dynamic imports and reads of environment variables. Treat findings as blocking for high-risk patterns and document the exceptions. The check is a pipeline run on a deliberately risky sample change that fails the stage, which shows the scanner is wired into the merge gate.
Staff reviews with people who understand the risk
Assign reviewers who know that a DAG is code with the credentials and network reach of its worker, not configuration. Require at least one reviewer from the platform or security team for changes that add imports, connections, variables, Kubernetes settings or outbound calls. Authors should not approve their own changes, and the reviewer list should be set in the repository rules rather than left to convention. The check is a sample of recent merges where each high-risk change shows a qualified approver who is not the author.
Gate deployment to the reviewed commit
Deploy only the artifact built from the approved commit, using signed or hash-pinned images or a sync from a single branch. Keep staging separate from production, and do not let workers or the DAG File Processor pull code from a mutable location that a developer can edit. Record which commit each environment runs. The check is a comparison between the commit hash on the protected branch and the version reported by the running scheduler, DAG File Processor and workers, which should match after each deployment.
Restrict who can read task logs
Because DAG code can print environment values and other sensitive content, treat task logs as data with its own access rules. Map the people and roles that can view logs in the UI, the API and any log store against the data each DAG handles. Remove broad read access for groups that do not own the pipeline. The check is an access review where each log reader's role is matched to the datasets their pipelines touch, with any mismatch corrected and the change recorded.
Verify that review and log access stay aligned
Repeat the controls on a fixed schedule set by your own policy and after changes to the repository, identity provider or Airflow roles. Confirm that branch rules have not drifted, that the static analysis stage still runs, and that log permissions still match the teams that own each pipeline. Keep the evidence (rule exports, pipeline records, deployment logs and access reviews) together so an assessor can trace a production DAG back to an approved change. The check is a dated record that each control was tested and any gaps were closed.
Repository and deployment controls for DAG delivery
The repository is the first gate. Because Airflow does not verify or sandbox DAG code, a change merged to the DAG repository is effectively a code change to the environment that runs it. Repository controls decide who can propose that change and who can approve it. Branch protection and required reviews stop a single author from merging unreviewed code to the branch that deploys. They do not stop a reviewer from approving malicious code that looks routine, and they do not stop someone with admin rights from changing the protection settings. Confirm how your hosting platform enforces protected branches, who holds administrator rights, and whether approvals must come from someone other than the author.
- Protected deployment branch: Only merges through reviewed pull requests reach the branch that Airflow reads.
- Required reviewers: At least one approver who is not the author, with a named owner for security-sensitive directories.
- Restricted administrators: A short list of people who can change branch protection, which should be logged and reviewed.
- Signed commits or tags: Where your platform supports them, these help show which identity produced a change.
- Dependency and requirement files: Changes to packages installed alongside DAGs deserve the same review as DAG code.
Check that no bypass exists for administrators or CI service accounts, and that review history is retained for audits.
Separation of duties means that the people who write DAGs are not the only people who decide what reaches production. The Airflow security model makes DAG authors effectively privileged, so the deployment path should not let one author control the code, the review and the release. Separation reduces the chance that a single compromised account or careless change goes live. It does not remove the risk from a trusted reviewer who is also an author, and it adds process cost in small teams. Ask who can push to the repository, who can approve, who can change the CI pipeline, and who can change the Airflow deployment configuration.
- Author and approver split: Authors cannot approve their own pull requests on production paths.
- Pipeline ownership: The people who edit CI jobs and deployment manifests are a separate group from DAG authors, or changes to those files receive a second review.
- Access to Airflow itself: Deployment rights, Kubernetes secrets and the metadata database should be managed by the platform team, not by DAG authors.
- Emergency change path: A documented, logged route for urgent fixes, with after-the-fact review.
- Access reviews: Periodic checks that group membership still matches these roles.
For a small team, the practical question is which approvals can be done by someone outside the author's immediate working group.
DAG code reaches Airflow through a delivery path, and each path places the trust boundary in a different spot. An image build bakes DAGs into a container image that is built, scanned and promoted like any other artifact. Git sync pulls a branch or tag into the running environment. A shared volume mounts a directory that someone copies files into. The choice affects who can change running code, how fast a change lands, and how easily you can prove what ran. Confirm which method your deployment uses, which identity can write to the source, and whether a change can reach workers without passing through the review gate.
- Image build: Code is reviewed before the build, and the image digest identifies exactly what ran. Anyone who can push to the registry can change production code unless registry rights are restricted.
- Git sync: The synced branch or tag must be the protected one, and the sync credential should be read-only with limited scope.
- Shared volume: Write access to the volume is equivalent to deploy access, so it needs the strictest permissions and monitoring.
- Parser and worker parity: Confirm that the DAG File Processor, scheduler and workers see the same code version.
- Pinned references: Pin tags or digests where possible so that a branch update does not silently change production.
Ask your platform team to document each path and the identity that can write to it.
Environment promotion moves DAG code from a development or staging Airflow to production through defined steps. Its main value is that code runs in a non-production environment with production-like settings before it can affect real data. It does not make code safe by itself, because a staging environment with production credentials or shared metadata is not a real test boundary, and because a malicious author can behave differently in staging than in production. Promotion controls should specify what is tested, who approves the move, and whether staging and production share connections, variables or secret backends.
- Separate environments: Distinct Airflow deployments, metadata databases and secret stores for staging and production where feasible.
- Promotion by reviewed artifact: The same reviewed commit or image digest is promoted, not rebuilt from a different source.
- Automated checks: Linting, tests and static analysis run before promotion. Use these as gates, not as proof of safety.
- Credential scope: Staging connections should point to non-production data, because DAG code can read any connection it can reach.
- Rollback record: Keep the previous artifact available so a bad release can be reverted.
Confirm whether your staging environment uses production credentials, and who can trigger the move to production.
Which access model fits your team size and data sensitivity
This table compares three ways to organize Airflow access: one trusted team on a single instance, separate instances per trust domain, and shared instances using multi-team mode, which Airflow 3.2 marks as experimental. Read each row against who can merge DAG code, because that person effectively holds the access the other columns describe. The main takeaway is that a shared instance only separates teams as far as the platform enforces, so confirm the boundary before you rely on it.
| Option | Who can merge DAG code | What they can reach | When it fits | What to confirm |
|---|---|---|---|---|
| One trusted team, one instance | Members of the single data team, after code review | All DAGs, connections, variables and task logs on the instance, and the workers that run them | Small group of engineers who all have equal access to the data and credentials | Review and merge rules in your repository, and who is allowed to approve pull requests |
| Separate instances per trust domain | Authors within that domain only | Only the DAGs, workers, connections and metadata database of their own instance | Teams with different data sensitivity, regulatory scope or administrators that must not overlap | Network paths between instances are blocked, and each instance has its own deployment pipeline and credentials |
| Shared instance with multi-team mode (experimental in 3.2) | Authors across several teams, subject to team-scoped permissions | Team-scoped RBAC, variables and connections, while the workers, DAG File Processor and metadata database remain shared | Several teams with similar sensitivity who accept experimental features and shared infrastructure | Whether the feature is stable for your version, which resources it does not scope, and whether a DAG author can still read another team's secrets through code |
| Shared instance without multi-team mode | Any author who can merge to the shared repository | Everything on the instance, because the security model does not sandbox DAG code | Rarely suitable where teams do not trust each other with credentials | Only use this if you accept that any merged DAG can run code on workers |
| Hosted or managed Airflow service | Depends on the provider's tenancy design | Depends on the provider's isolation controls and shared components | Teams that want the provider to operate infrastructure | Whether multi-team mode is supported, and how the provider isolates workers and metadata |
Where the trust model stops and separate controls take over
The DAG author trust assumption does not disappear when you add controls. Several sibling topics cover the controls that reduce it: worker isolation through the Task Execution API, secrets handling and masking, JWT and REST API access, audit logs, and multi-team limits. Each one narrows what a malicious or careless DAG author can reach, but none of them turns DAG code into untrusted input. The security model is explicit that DAG authors can effectively run arbitrary code on workers, the DAG File Processor and the Triggerer, and can change the state of any task instance. Treat the isolation work as damage reduction for honest mistakes and compromised accounts, and keep the trust decision at the level of who can merge code.
A separate Airflow instance is the safer choice when the people who can merge DAGs should not be trusted with what the other DAGs can reach. Teams that handle different regulated data, different production credentials, or different change-approval regimes usually meet this point first. The experimental multi-team mode in Airflow 3.2 shares the scheduler, workers and metadata database, so it limits access in the UI and API rather than removing shared execution. Before deciding, ask the platform owner to confirm in writing what each control covers in your release, and which shared components remain common to all teams. Those answers, not a team count or a rule of thumb, should set the boundary.
The practical test is simple: if a DAG author in team A could, through a merged change, read a secret, reach a database or alter a run that team B depends on, and your review process would not catch it first, the controls are not enough on their own. Write that boundary down before the first DAG is deployed. Then confirm the controls that enforce it with your own tests in a staging environment, including a deliberately unsafe DAG in a non-production cluster. Keep the review, repository branch protection and deployment gates in front of every DAG change regardless of which isolation controls you adopt, because those gates are what the security model relies on.
Security and operational considerations for DAG code
Once DAG code is trusted to run on workers, the surrounding controls decide how much damage a bad or compromised DAG can do. The cards below cover the controls that sit around DAG code: what logs expose, what the metadata database holds, which Airflow line you run, what gets installed beside DAGs, who changes DAG files, and how you respond when a DAG turns out to be malicious.
Restrict access to task logs
Task logs are where DAG code prints what it sees, including environment values, tokens and connection details that a task pulled at runtime. The security model recommends restricting access to task logs for this reason. Confirm which roles can open task logs in the UI and the API, and treat log storage as sensitive data with its own access and retention rules. Test with a DAG that prints a dummy secret to confirm your masking and access settings behave as you expect.
Keep the metadata database out of task reach
Workers do not receive database credentials and cannot reach the metadata database directly, but the DAG File Processor and Triggerer only have software guards that do not stop a deliberately malicious DAG author. Verify that no connection string, database password or session configuration is visible to DAG code through environment variables, mounted files or the Airflow configuration the process can read. Check network policies so only the components that need the database can reach it.
Stay on a supported Airflow line
Airflow 2 reached end of life on April 22, 2026, after which it gets no fixes. Airflow 3 was first released on April 22, 2025, and the limited-maintenance policy covers only security and critical bug fixes. Record which line and patch level each environment runs, and plan upgrades before a line leaves support. Ask your vendor or team to confirm the upgrade path from your current version before scheduling work.
Review third-party packages beside DAGs
Packages installed into the Airflow environment run with the same reach as DAG code, so a dependency is part of the trust boundary. Pin versions with constraints, record the source of each package, and review additions in the same pull request as the DAG that needs them. Scan the image or environment for known vulnerabilities on each build, and confirm which packages your team has approved for use in production.
Monitor who changes DAG files
Because anyone who can merge DAG code can run code on workers, the review record is your main control. Require pull request approval from someone other than the author, protect the main branch, and alert on direct pushes or changes to the deployment path. Compare what is deployed with what is merged, so an edit made outside the repository is visible. Keep these records long enough for your audit or incident process to use them.
Plan incident response for a malicious DAG
If a DAG proves malicious, assume it ran on workers and could have changed the state of any task instance. Disable the DAG, revoke credentials that tasks could read, review task logs and the audit trail for the affected period, and rebuild affected worker environments from a known-good image. Rehearse this with your security team before you need it, and ask your team or partner which evidence the Airflow logs and database retain for your deployment.
Questions teams ask about DAG author access
Is a code review alone enough to control what DAG authors can do?
No. A code review reduces the chance that a bad DAG reaches production, but it does not limit what a DAG can do once it runs. Airflow does not verify, check or sandbox DAG code, so anyone whose change is merged can run arbitrary code on workers, the DAG File Processor and the Triggerer, and can change the state of any task instance. Review is one control among several. It works best alongside static analysis in CI, protected branches that require a second approver, restricted access to task logs, and deployment rules that keep credentials away from the code path authors can edit. The Airflow security model recommends reviewing DAG code before deployment, including static analysis and pull request review.
Can Airflow sandbox DAG code so authors cannot cause damage?
No. Airflow does not provide a sandbox for DAG code. The security model describes software guards in the DAG File Processor and Triggerer that do not stop a deliberately malicious DAG author. Workers are better protected in one respect: they do not receive database credentials and cannot reach the metadata database directly. Even so, a DAG can still print sensitive environment values into task logs and act on any system the worker can reach. Isolation therefore has to come from the surrounding design: which credentials workers hold, how the network is segmented, who can read logs, and whether separate Airflow instances are used for teams that should not trust each other.
How much effort does a DAG review and repository hardening project take?
The effort depends on the size and shape of your DAG estate, not on a fixed package. No duration is given here because it varies widely. The main drivers are the number of repositories and DAG authors, whether branch protection and required reviews already exist, how many DAGs connect to sensitive systems, whether CI already runs linting and static checks, and how much tooling must be built, such as custom scanners or review rules. Ask for a written scope that lists the repositories, the controls to implement, the environments covered and the evidence each control produces. A fixed-scope agreement fixes those deliverables before work starts.
Can our own team do this work without a partner?
Often yes, if you have engineers who know Git hosting administration, CI pipelines and Airflow deployment. Most of the controls are standard repository settings and pipeline steps: protected branches, required reviewers, code owners, secret scanning and static analysis. The harder parts are mapping which DAGs touch which credentials, separating worker and scheduler permissions, and deciding how to restrict log access without breaking support workflows. Those decisions need someone who understands both the Airflow security model and your data flows. A partner can run that analysis, implement the controls and document them. Your team can do the same work if it has the time and the skills, and it keeps the knowledge in-house from the start.
What does the work need from our people?
Plan for three groups. Repository administrators need to change branch protection, code owner rules, CI requirements and access rights on the DAG repositories. Platform owners need to confirm how Airflow is deployed, where workers run, which secrets and connections they can read, and how DAGs reach the environment. Security reviewers need to define which DAG patterns are unacceptable, approve the review rules, and check the evidence. Ask for these roles to be named at the start, with time reserved for them. Delays usually come from access requests and unanswered questions about existing DAGs, not from the technical changes.
When should we run separate Airflow instances instead of sharing one?
Separate instances are the safer choice when teams should not be able to run code in each other's context, or when a team's DAGs touch systems that another team must not reach. Review and repository controls cannot make a shared instance a security boundary, because any DAG author can affect workers and task instances. Airflow's experimental multi-team mode narrows some access, but the shared components remain shared, so confirm its limits before relying on it. Ask whether the regulatory scope of each team's data requires separation, how many environments you need, and who will operate each instance. Each additional instance adds upgrade, monitoring and backup work that recurs.
What costs go up or down in a hardening project?
The main cost is skilled time, split between the people who design the controls and the people who apply them to existing repositories. One-time costs include the initial review of DAG estates, repository configuration, CI pipeline changes and documentation. Recurring costs include reviewing new DAGs, maintaining scanner rules, rotating credentials, upgrading Airflow and keeping evidence current. Costs rise when there are many repositories, weak existing review habits, DAGs that already hold broad credentials, or several teams with different trust levels. They fall when DAGs are generated from a small set of reviewed templates and secrets are kept out of author-editable code. Ask any quote to itemize one-time and recurring work separately.
How DeployOpen scopes DAG author security work
DeployOpen plans, implements, hardens and documents self-hosted Apache Airflow inside your own cloud accounts, data centers or air-gapped networks, and the DAG author trust model is one of the first things we scope. Because Airflow does not sandbox DAG code, the work that follows from it is mostly about your process and infrastructure: who may merge DAG code, how that code is reviewed and promoted, which service accounts and secrets each worker can reach, and how task logs are restricted. Those decisions are agreed with your security, data and platform owners before any configuration changes are made, so the scope reflects your actual risk rather than a generic template.
Most engagements are fixed-scope. Before work starts, DeployOpen and your team agree in writing on the scope, the deliverables and the timeline, along with the systems in scope, the environments involved and who signs off on each control. For the DAG author topic, a typical written scope lists the repositories and branch protections to review, the CI checks to add, the worker and metadata database boundaries to verify, and the evidence you will receive at the end. Ask for each item to be named explicitly so you can check later whether it was delivered. Security testing of the deployed environment is available as a separate, scoped engagement. Ongoing support, upgrades and continuous testing are available as retainers, which suit teams that add DAG authors or teams over time.
DeployOpen does not publish a price list. A quote follows from the written scope, and the main cost drivers are the number of environments, the number of DAG repositories and teams, the integrations to secrets stores and identity providers, and the amount of existing DAG code to review. DeployOpen prepares systems, configuration and evidence that support compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments, so ask any auditor you engage which evidence they expect from the DAG review and deployment controls before the scope is finalized.
