fix(kanban): enforce worker task-ownership on destructive tool calls by teknium1 · Pull Request #19713 · NousResearch/hermes-agent

teknium1 · 2026-05-04T11:53:55Z

Closes #19534 (security).

Summary

Worker processes can no longer complete/block/heartbeat sibling or cross-tenant tasks by passing an explicit task_id that differs from the one the dispatcher spawned them for.

Threat model

Reporter (@BlueBirdBack) demonstrated: worker spawned for t_A (with HERMES_KANBAN_TASK=t_A) calls kanban_complete(task_id="t_B", summary="HIJACK") and receives {"ok": true, "task_id": "t_B", ...}. Task B is now marked done with the attacker's summary and metadata, and its downstream dependencies unblock prematurely. A buggy worker or a prompt-injected one can corrupt handoffs and cross-tenant runs.

Fix

_enforce_worker_task_ownership(tid) in tools/kanban_tools.py. When HERMES_KANBAN_TASK is in env and the requested tid doesn't match, the tool returns a structured error pointing the caller at the correct escape hatches (kanban_comment for information handoff, kanban_create for follow-up work).

Applied to the three destructive handlers:

_handle_complete
_handle_block
_handle_heartbeat

Orchestrators are exempt. Profiles with the kanban toolset enabled but no HERMES_KANBAN_TASK in env (the orchestrator case, per #18968) retain full mutation access — their job is routing, which sometimes includes closing out child tasks on behalf of the child.

Read-only / create-only tools stay unrestricted:

kanban_show — workers legitimately read parent/sibling context
kanban_comment — cross-task comments ARE the handoff mechanism
kanban_create — orchestrator fan-out, worker follow-up spawning
kanban_link — parent/child linking

Validation

E2E grid tested against the worktree with real imports:

scenario	expected	actual
worker complete(foreign)	reject	`refusing to mutate` error, sibling untouched
worker complete(own, explicit)	allow	`ok: true`
worker complete(implicit, no arg)	allow	`ok: true`
worker block(foreign)	reject	`refusing to mutate`
worker heartbeat(foreign)	reject	`refusing to mutate`
orchestrator complete(any)	allow	`ok: true`

5 regression tests added in tests/tools/test_kanban_tools.py covering the grid. tests/tools/test_kanban_tools.py — 36/36 pass.

Closes #19534 (security). A worker spawned by the kanban dispatcher has HERMES_KANBAN_TASK set to its own task id. The destructive tools (kanban_complete, kanban_block, kanban_heartbeat) resolved task_id via _default_task_id() which preferred an explicit arg over the env var, with no ownership check — so a buggy or prompt-injected worker could complete / block / heartbeat any OTHER task (sibling, cross-tenant, anything) by supplying its id. Reporter's repro: worker for t_A passed task_id=t_B to kanban_complete and got {"ok": true}. Fix: add _enforce_worker_task_ownership(tid). If HERMES_KANBAN_TASK is set and tid doesn't match, return a structured tool error with guidance to use kanban_comment (for information handoff across tasks) or kanban_create (for follow-up work). Orchestrator profiles (no env var, but kanban toolset enabled per #18968) are exempt — their job is routing and sometimes includes closing out child tasks. Kept unrestricted (deliberately): - kanban_show — workers legitimately read parent/sibling handoff context - kanban_comment — cross-task comments are the handoff mechanism - kanban_create — orchestrator fan-out, worker follow-up spawning - kanban_link — parent/child linking Tests: 5 new regression tests in tests/tools/test_kanban_tools.py covering the grid (worker-attacks-foreign ×3 tools, worker-own-task preserved, orchestrator-unrestricted). 36/36 pass.

- Renames test_comment_custom_author -> test_comment_ignores_caller_supplied_author and inverts its assertion: an args['author'] override is silently ignored; the author always comes from HERMES_PROFILE. - Adds test_comment_schema_omits_author_override to assert the 'author' property is gone from KANBAN_COMMENT_SCHEMA so the forgery surface stays closed if someone re-adds the schema field by accident. - Adds test_worker_can_comment_on_foreign_task to pin the #19713 policy decision: cross-task commenting must remain unrestricted. Without this guard, a future change accidentally adding _enforce_worker_task_ownership to _handle_comment would close the documented handoff channel between tasks.

Comments are injected into the next worker's system prompt by build_worker_context() as '**{author}** (timestamp): {body}'. The previous code accepted args['author'] as a free-form override and exposed it on KANBAN_COMMENT_SCHEMA, which let a worker: 1. Receive a prompt-injection in a malicious task body. 2. Call kanban_comment with author='hermes-system' (or any other authoritative-looking name) on a sibling task. 3. The next worker assigned to that sibling task sees the forged comment in its boot context as what reads like a system-authored directive. Always derive author from HERMES_PROFILE (the dispatcher already sets this per worker at hermes_cli/kanban_db.py:3718), and remove the 'author' property from the tool schema so the LLM can't see the override surface. Cross-task commenting itself remains unrestricted (see #19713) — comments are the deliberate handoff channel between tasks; only the author-override surface is closed. Co-authored-by: kshitijk4poor <82637225+kshitijk4poor@users.noreply.github.com>

- Renames test_comment_custom_author -> test_comment_ignores_caller_supplied_author and inverts its assertion: an args['author'] override is silently ignored; the author always comes from HERMES_PROFILE. - Adds test_comment_schema_omits_author_override to assert the 'author' property is gone from KANBAN_COMMENT_SCHEMA so the forgery surface stays closed if someone re-adds the schema field by accident. - Adds test_worker_can_comment_on_foreign_task to pin the #19713 policy decision: cross-task commenting must remain unrestricted. Without this guard, a future change accidentally adding _enforce_worker_task_ownership to _handle_comment would close the documented handoff channel between tasks.

Comments are injected into the next worker's system prompt by build_worker_context() as '**{author}** (timestamp): {body}'. The previous code accepted args['author'] as a free-form override and exposed it on KANBAN_COMMENT_SCHEMA, which let a worker: 1. Receive a prompt-injection in a malicious task body. 2. Call kanban_comment with author='hermes-system' (or any other authoritative-looking name) on a sibling task. 3. The next worker assigned to that sibling task sees the forged comment in its boot context as what reads like a system-authored directive. Always derive author from HERMES_PROFILE (the dispatcher already sets this per worker at hermes_cli/kanban_db.py:3718), and remove the 'author' property from the tool schema so the LLM can't see the override surface. Cross-task commenting itself remains unrestricted (see #19713) — comments are the deliberate handoff channel between tasks; only the author-override surface is closed. Co-authored-by: kshitijk4poor <82637225+kshitijk4poor@users.noreply.github.com>

- Renames test_comment_custom_author -> test_comment_ignores_caller_supplied_author and inverts its assertion: an args['author'] override is silently ignored; the author always comes from HERMES_PROFILE. - Adds test_comment_schema_omits_author_override to assert the 'author' property is gone from KANBAN_COMMENT_SCHEMA so the forgery surface stays closed if someone re-adds the schema field by accident. - Adds test_worker_can_comment_on_foreign_task to pin the #19713 policy decision: cross-task commenting must remain unrestricted. Without this guard, a future change accidentally adding _enforce_worker_task_ownership to _handle_comment would close the documented handoff channel between tasks.

…ousResearch#19713) Closes NousResearch#19534 (security). A worker spawned by the kanban dispatcher has HERMES_KANBAN_TASK set to its own task id. The destructive tools (kanban_complete, kanban_block, kanban_heartbeat) resolved task_id via _default_task_id() which preferred an explicit arg over the env var, with no ownership check — so a buggy or prompt-injected worker could complete / block / heartbeat any OTHER task (sibling, cross-tenant, anything) by supplying its id. Reporter's repro: worker for t_A passed task_id=t_B to kanban_complete and got {"ok": true}. Fix: add _enforce_worker_task_ownership(tid). If HERMES_KANBAN_TASK is set and tid doesn't match, return a structured tool error with guidance to use kanban_comment (for information handoff across tasks) or kanban_create (for follow-up work). Orchestrator profiles (no env var, but kanban toolset enabled per NousResearch#18968) are exempt — their job is routing and sometimes includes closing out child tasks. Kept unrestricted (deliberately): - kanban_show — workers legitimately read parent/sibling handoff context - kanban_comment — cross-task comments are the handoff mechanism - kanban_create — orchestrator fan-out, worker follow-up spawning - kanban_link — parent/child linking Tests: 5 new regression tests in tests/tools/test_kanban_tools.py covering the grid (worker-attacks-foreign ×3 tools, worker-own-task preserved, orchestrator-unrestricted). 36/36 pass.

Comments are injected into the next worker's system prompt by build_worker_context() as '**{author}** (timestamp): {body}'. The previous code accepted args['author'] as a free-form override and exposed it on KANBAN_COMMENT_SCHEMA, which let a worker: 1. Receive a prompt-injection in a malicious task body. 2. Call kanban_comment with author='hermes-system' (or any other authoritative-looking name) on a sibling task. 3. The next worker assigned to that sibling task sees the forged comment in its boot context as what reads like a system-authored directive. Always derive author from HERMES_PROFILE (the dispatcher already sets this per worker at hermes_cli/kanban_db.py:3718), and remove the 'author' property from the tool schema so the LLM can't see the override surface. Cross-task commenting itself remains unrestricted (see NousResearch#19713) — comments are the deliberate handoff channel between tasks; only the author-override surface is closed. Co-authored-by: kshitijk4poor <82637225+kshitijk4poor@users.noreply.github.com>

- Renames test_comment_custom_author -> test_comment_ignores_caller_supplied_author and inverts its assertion: an args['author'] override is silently ignored; the author always comes from HERMES_PROFILE. - Adds test_comment_schema_omits_author_override to assert the 'author' property is gone from KANBAN_COMMENT_SCHEMA so the forgery surface stays closed if someone re-adds the schema field by accident. - Adds test_worker_can_comment_on_foreign_task to pin the NousResearch#19713 policy decision: cross-task commenting must remain unrestricted. Without this guard, a future change accidentally adding _enforce_worker_task_ownership to _handle_comment would close the documented handoff channel between tasks.