[shivaam]

Execution API JWTs identify a single task instance, but the existing XCom POST route also accepts the Dag, run, task, and map identity in the URL and query parameters. Previously, a valid task token could supply different coordinates and write an XCom under another task instance identity within its permitted team boundary.

This change keeps the existing route for Task SDK and API server compatibility while making the JWT-resolved task instance authoritative for writes. The endpoint rejects a missing token task instance or any Dag, run, task, or map-index mismatch with a structured 403 response, and uses the resolved identity for both XComModel and TaskMap writes.

The in-process Execution API used by local task supervisors has no worker JWT. It overrides the write-identity dependency and resolves the task instance from the trusted route coordinates, preserving dag.test() and related in-process XCom behavior for both mapped and unmapped tasks.

This is intentionally the smallest compatible first slice of #70080. XCom reads retain explicit source identifiers because cross-task, cross-Dag, historical, and mapped pulls need to address task instances other than the authenticated caller. Removing identifiers from the write URL can follow through an API-versioned endpoint once mixed Task SDK/API server compatibility is designed.

Related: #70080

Testing

• Focused Breeze validation: 70 passed (67 Execution API XCom route tests plus three in-process regressions covering unmapped writes, mapped writes, and missing task-instance rejection).
• prek run ruff --from-ref upstream/main --to-ref HEAD
• prek run ruff-format --from-ref upstream/main --to-ref HEAD
• Regular pre-commit checks passed for the changed files; the aggregate run encountered an unrelated providers/common/sql mypy stub error on current main.
• Final-revision Breeze daemon validation with PostgreSQL 14 and LocalExecutor: two real scheduler runs completed with 22/22 successful task instances, covering Task SDK XCom push/pull and mapped indexes 0-2.
• Real JWT/API boundary probe: an own-task write returned 201; cross-task, cross-run, map-index mismatch, and missing-task-instance writes returned structured 403 access_denied responses; PostgreSQL contained no forbidden XCom rows.

---

Was generative AI tooling used to co-author this PR?

• Yes (OpenAI Codex)

Generated-by: OpenAI Codex following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.

[potiuk]

Hello @shivaam - thank you for your contributions to Apache Airflow!

The Airflow community has introduced a limit of 5 open pull requests at a time for contributors without write access to the repository. You currently have 6 open pull requests, so - as a one-time step of introducing the limit - we closed the ones where maintainers have not engaged yet:

• Prevent tasks from writing XComs as other task instances #70969 - Prevent tasks from writing XComs as other task instances
• Prevent new setup-time database pre-cleaning in unit tests #71589 - Prevent new setup-time database pre-cleaning in unit tests

These pull requests stay open because maintainers are already engaged in them - they count towards your limit:

• Handle missed deadline alerts when DagRuns fail #68961 - Handle missed deadline alerts when DagRuns fail
• Speed up Celery task publishing with Redis pipelines #70455 - Speed up Celery task publishing with Redis pipelines
• Batch triggerer unused trigger cleanup deletes #70961 - Batch triggerer unused trigger cleanup deletes
• Add Dag ID filtering to Assets search #70971 - Add Dag ID filtering to Assets search

This is not a judgement of you or of your changes. We never told contributors before that opening many pull requests at once was a problem, so there is nothing to feel bad about - and nothing is lost: your branches, commits and the review history stay where they are.

What we ask you to do is to make your first prioritization decision: choose which of the pull requests above matter most to you, and reopen them (up to 5 open at a time, including the ones still open) with the "Reopen pull request" button or gh pr reopen <PR_NUMBER> --repo apache/airflow. Reopen the ones you are ready to follow through - keep them rebased, respond to review comments and fix failing checks.

While your pull requests are waiting for review, the most valuable thing you can do is help in other ways - reviewing other contributors' pull requests, helping with issues, and taking part in the discussions on the devlist and Slack.

Why we introduced the limit, what it means for you and how to reopen or restore a pull request is explained in https://github.com/apache/airflow/blob/main/contributing-docs/32_open_pull_request_limit.rst.

---

Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting