referencing #40671

[abutareqaljaber-code]

Self Checks

• I have read the Contributing Guide and Language Policy.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

Update, with real test data: tested a parameter-renaming mitigation
(see #40671) using real disposable tasks so the Agent had genuine matches
to find. Results revealed a second, distinct failure mode beyond the
original zero-tool-call fabrication:

	Zero-call fabrication	Wrong-parameter dispatch
Tool dispatched?	No	Yes
Runner accepts as success?	Yes (no validation)	Yes (no validation)
Failure locus	Runner loop	Model hallucinates argument value
DB side-effect	None	Row written with wrong identifier
Detection difficulty	Empty trace, easy to spot	Row looks legitimate, wrong record targeted

The wrong-parameter case is arguably higher severity: a zero-call
fabrication leaves no trace and a human audit catches the absence. A
wrong-argument call writes a row that looks legitimate — an approver
trusting the description rather than independently verifying the actual
identifier would approve based on false context.

Revising the ask accordingly: the proposed guard should validate not
just that a tool was called, but that the tool's actual response contains
a verifiable identifier matching what was requested (e.g. the real
task_id echoed back by the underlying API), not merely that
tool_responses is non-empty. This closes both failure modes with one
mechanism.

Full trial data with real task IDs and the exact "Team not authorized"
evidence for the wrong-parameter case is in #40671.

2. Additional context or comments

No response

3. Can you help us with this feature?

• I am interested in contributing to this feature.

[abutareqaljaber-code]

@dosu

waiting for your feedback on the Fu
ll trial data with real task IDs and the exact "Team not authorized"
evidence for the wrong-parameter case is in #40671.

[dosubot]

Thanks for the detailed follow-up and linking the trial data from #40671. Your investigation surfaces two distinct failure modes worth separating clearly:

1. Zero-call fabrication (the original #40671 bug) — The FC runner loop accepts a terminal text response even when zero tool_calls were emitted. function_call_state is set to False at the top of each iteration and only flips to True if check_tool_calls() or check_blocking_tool_calls() finds tool calls [1]. When the model responds with text instead, the loop exits and Dify returns the fabricated success with an empty trace.

2. Wrong-parameter dispatch (the new failure mode in this issue) — The model does emit a tool_call, so Dify dispatches it via ToolEngine.agent_invoke [2], but with a hallucinated argument value (e.g., a wrong task_id). The tool executes against the wrong record, the runner accepts whatever the tool returns as success, and a row that looks legitimate gets written. The "Team not authorized" error you observed is the underlying API signaling the identifier was wrong — but the runner has no mechanism to treat that as a validation failure.

What Dify currently validates vs. doesn't:

Layer	Validated today?
Tool parameter type (string, number, etc.)	✅ Yes, via cast_parameter_value() [3]
Tool parameter presence (required fields)	✅ Yes [3]
Whether a tool call was emitted at all	❌ No
Whether the tool's response contains the expected identifier	❌ No

Your proposed guard — response-content validation — is the right framing. The fix would require the runner to extract a verifiable identifier from the tool response, compare it against what was requested, and treat a mismatch (or an error like "Team not authorized") as a failure rather than a success. This isn't trivially generic — it needs the tool to declare what "success" looks like (e.g., an echoed identifier field), or the application layer to supply a verification predicate.

Your severity point is well-taken: a wrong-argument call that writes a legitimate-looking DB row is harder to catch in audit than an empty trace from a zero-call fabrication. That distinction makes this worth keeping prominent in the feature request.

Practical interim mitigation: add a verification step in your workflow — after the agent tool call, use a second tool call or HTTP request node that fetches the record by the expected task_id and asserts it exists/was modified correctly. This closes the wrong-parameter hole at the workflow level without waiting for runner-layer validation.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.