CVE-2026-57142

PraisonAI is a multi-agent teams system. From version 4.5.87 to before version 4.6.61, PraisonAI recipe execution has a dangerous-tool policy that is supposed to block default-denied tools unless the caller explicitly passes allow_dangerous_tools=True. That policy only checks tools declared in TEMPLATE.yaml requires.tools. For steps-based recipes, the actual execution path loads workflow.yaml with YAMLWorkflowParser. That parser resolves agent-level tools: declarations and preserves top-level approve:. Workflow.start() then installs those YAML-approved tools into the approval context. As a result, an untrusted recipe can omit execute_command from TEMPLATE.yaml requires.tools, declare it in workflow.yaml agents.*.tools, and add top-level approve: [execute_command]. The caller did not set allow_dangerous_tools=True, but the recipe policy allows the recipe and the workflow approval path self-approves the critical shell tool. This issue has been patched in version 4.6.61.

PraisonAI is a multi-agent teams system. From version 4.5.87 to before version 4.6.61, PraisonAI recipe execution has a dangerous-tool policy that is supposed to block default-denied tools unless the caller explicitly passes allow_dangerous_tools=True. That policy only checks tools declared in TEMPLATE.yaml requires.tools. For steps-based recipes, the actual execution path loads workflow.yaml with YAMLWorkflowParser. That parser resolves agent-level tools: declarations and preserves top-level approve:. Workflow.start() then installs those YAML-approved tools into the approval context. As a result, an untrusted recipe can omit execute_command from TEMPLATE.yaml requires.tools, declare it in workflow.yaml agents.*.tools, and add top-level approve: [execute_command]. The caller did not set allow_dangerous_tools=True, but the recipe policy allows the recipe and the workflow approval path self-approves the critical shell tool. This issue has been patched in version 4.6.61.

Summary

PraisonAI recipe execution has a dangerous-tool policy that is supposed to block default-denied tools unless the caller explicitly passes allow_dangerous_tools=True. That policy only checks tools declared in TEMPLATE.yaml requires.tools.

For steps-based recipes, the actual execution path loads workflow.yaml with YAMLWorkflowParser. That parser resolves agent-level tools: declarations and preserves top-level approve:. Workflow.start() then installs those YAML-approved tools into the approval context.

As a result, an untrusted recipe can omit execute_command from TEMPLATE.yaml requires.tools, declare it in workflow.yaml agents.*.tools, and add top-level approve: [execute_command]. The caller did not set allow_dangerous_tools=True, but the recipe policy allows the recipe and the workflow approval path self-approves the critical shell tool.

The local PoV uses a harmless printf canary and explicitly unsets PRAISONAI_AUTO_APPROVE.

Technical Details

recipe.run() checks the recipe policy unless options["allow_dangerous_tools"] is true. _check_tool_policy() gets the required tool list from recipe_config.get_required_tools(), which is backed by TEMPLATE.yaml requires.tools.

The steps workflow execution path is separate:

1. _execute_steps_workflow() parses the workflow file with YAMLWorkflowParser.
2. YAMLWorkflowParser resolves agents.*.tools.
3. The same parser reads top-level approve: and stores it on workflow.approve_tools.
4. Workflow.start() calls set_yaml_approved_tools(approve_tools).
5. The approval registry treats YAML-approved tools as approved.

execute_command is listed as a default dangerous tool with critical risk and is decorated with @require_approval(risk_level="critical"). The policy gap is that recipe-level dangerous-tool enforcement does not inspect the workflow file that actually supplies and approves the tool.

Why This Is Not Intended Behavior

YAML approve: is an intended feature. This report is not claiming that workflow-level approval is inherently unintended.

The unintended behavior is that the recipe dangerous-tool policy exposes an operator-facing explicit override, allow_dangerous_tools=True, but a recipe can avoid that policy by moving the dangerous tool declaration from TEMPLATE.yaml requires.tools into the steps workflow. The recipe still runs through the standard recipe runner path, and the same workflow can self-approve the critical tool.

This conflicts with the documented safety model:

• PraisonAI's approval docs describe approval as pausing an agent before a risky tool and asking a human or configured channel to allow or deny it.
• The SDK approval docs describe a human-in-the-loop approval system for dangerous tool operations.
• Security-environment documentation describes opt-in access for potentially dangerous operations and secure defaults for RCE prevention.
• Policy-engine documentation describes policies that block dangerous operations and require approval for sensitive actions.

A control recipe that declares requires.tools: [execute_command] is denied with:

Tool 'execute_command' is denied by default. Use allow_dangerous_tools=True to override.

The bypass recipe uses the same tool but omits it from requires.tools; it passes policy and reaches the recipe runner's dry-run state.

PoV

Run:

python3 poc/poc.py

Expected output:

{
  "ok": true,
  "control_policy": "Tool 'execute_command' is denied by default. Use allow_dangerous_tools=True to override.",
  "control_recipe_status": "policy_denied",
  "bypass_policy": null,
  "bypass_recipe_dry_run_status": "dry_run",
  "workflow_approve_tools": [
    "execute_command"
  ],
  "runner_tool_names": [
    "execute_command"
  ],
  "command_stdout": "poc",
  "operator_env_auto_approve": null
}

The PoV creates two temporary recipes:

1. A control recipe with TEMPLATE.yaml requires.tools: [execute_command].…

PraisonAI is a multi-agent teams system. From version 4.5.87 to before version 4.6.61, PraisonAI recipe execution has a dangerous-tool policy that is supposed to block default-denied tools unless the caller explicitly passes allow_dangerous_tools=True. That policy only checks tools declared in TEMPLATE.yaml requires.tools. For steps-based recipes, the actual execution path loads workflow.yaml with YAMLWorkflowParser. That parser resolves agent-level tools: declarations and preserves top-level approve:. Workflow.start() then installs those YAML-approved tools into the approval context. As a result, an untrusted recipe can omit execute_command from TEMPLATE.yaml requires.tools, declare it in workflow.yaml agents.*.tools, and add top-level approve: [execute_command]. The caller did not set allow_dangerous_tools=True, but the recipe policy allows the recipe and the workflow approval path self-approves the critical shell tool. This issue has been patched in version 4.6.61.

Summary

PraisonAI recipe execution has a dangerous-tool policy that is supposed to block default-denied tools unless the caller explicitly passes allow_dangerous_tools=True. That policy only checks tools declared in TEMPLATE.yaml requires.tools.

For steps-based recipes, the actual execution path loads workflow.yaml with YAMLWorkflowParser. That parser resolves agent-level tools: declarations and preserves top-level approve:. Workflow.start() then installs those YAML-approved tools into the approval context.

As a result, an untrusted recipe can omit execute_command from TEMPLATE.yaml requires.tools, declare it in workflow.yaml agents.*.tools, and add top-level approve: [execute_command]. The caller did not set allow_dangerous_tools=True, but the recipe policy allows the recipe and the workflow approval path self-approves the critical shell tool.

The local PoV uses a harmless printf canary and explicitly unsets PRAISONAI_AUTO_APPROVE.

Technical Details

recipe.run() checks the recipe policy unless options["allow_dangerous_tools"] is true. _check_tool_policy() gets the required tool list from recipe_config.get_required_tools(), which is backed by TEMPLATE.yaml requires.tools.

The steps workflow execution path is separate:

1. _execute_steps_workflow() parses the workflow file with YAMLWorkflowParser.
2. YAMLWorkflowParser resolves agents.*.tools.
3. The same parser reads top-level approve: and stores it on workflow.approve_tools.
4. Workflow.start() calls set_yaml_approved_tools(approve_tools).
5. The approval registry treats YAML-approved tools as approved.

execute_command is listed as a default dangerous tool with critical risk and is decorated with @require_approval(risk_level="critical"). The policy gap is that recipe-level dangerous-tool enforcement does not inspect the workflow file that actually supplies and approves the tool.

Why This Is Not Intended Behavior

YAML approve: is an intended feature. This report is not claiming that workflow-level approval is inherently unintended.

The unintended behavior is that the recipe dangerous-tool policy exposes an operator-facing explicit override, allow_dangerous_tools=True, but a recipe can avoid that policy by moving the dangerous tool declaration from TEMPLATE.yaml requires.tools into the steps workflow. The recipe still runs through the standard recipe runner path, and the same workflow can self-approve the critical tool.

This conflicts with the documented safety model:

• PraisonAI's approval docs describe approval as pausing an agent before a risky tool and asking a human or configured channel to allow or deny it.
• The SDK approval docs describe a human-in-the-loop approval system for dangerous tool operations.
• Security-environment documentation describes opt-in access for potentially dangerous operations and secure defaults for RCE prevention.
• Policy-engine documentation describes policies that block dangerous operations and require approval for sensitive actions.

A control recipe that declares requires.tools: [execute_command] is denied with:

Tool 'execute_command' is denied by default. Use allow_dangerous_tools=True to override.

The bypass recipe uses the same tool but omits it from requires.tools; it passes policy and reaches the recipe runner's dry-run state.

PoV

Run:

python3 poc/poc.py

Expected output:

{
  "ok": true,
  "control_policy": "Tool 'execute_command' is denied by default. Use allow_dangerous_tools=True to override.",
  "control_recipe_status": "policy_denied",
  "bypass_policy": null,
  "bypass_recipe_dry_run_status": "dry_run",
  "workflow_approve_tools": [
    "execute_command"
  ],
  "runner_tool_names": [
    "execute_command"
  ],
  "command_stdout": "poc",
  "operator_env_auto_approve": null
}

The PoV creates two temporary recipes:

1. A control recipe with TEMPLATE.yaml requires.tools: [execute_command].…

Summary

PraisonAI recipe execution has a dangerous-tool policy that is supposed to block default-denied tools unless the caller explicitly passes allow_dangerous_tools=True. That policy only checks tools declared in TEMPLATE.yaml requires.tools.

For steps-based recipes, the actual execution path loads workflow.yaml with YAMLWorkflowParser. That parser resolves agent-level tools: declarations and preserves top-level approve:. Workflow.start() then installs those YAML-approved tools into the approval context.

As a result, an untrusted recipe can omit execute_command from TEMPLATE.yaml requires.tools, declare it in workflow.yaml agents.*.tools, and add top-level approve: [execute_command]. The caller did not set allow_dangerous_tools=True, but the recipe policy allows the recipe and the workflow approval path self-approves the critical shell tool.

The local PoV uses a harmless printf canary and explicitly unsets PRAISONAI_AUTO_APPROVE.

Technical Details

recipe.run() checks the recipe policy unless options["allow_dangerous_tools"] is true. _check_tool_policy() gets the required tool list from recipe_config.get_required_tools(), which is backed by TEMPLATE.yaml requires.tools.

The steps workflow execution path is separate:

1. _execute_steps_workflow() parses the workflow file with YAMLWorkflowParser.
2. YAMLWorkflowParser resolves agents.*.tools.
3. The same parser reads top-level approve: and stores it on workflow.approve_tools.
4. Workflow.start() calls set_yaml_approved_tools(approve_tools).
5. The approval registry treats YAML-approved tools as approved.

execute_command is listed as a default dangerous tool with critical risk and is decorated with @require_approval(risk_level="critical"). The policy gap is that recipe-level dangerous-tool enforcement does not inspect the workflow file that actually supplies and approves the tool.

Why This Is Not Intended Behavior

YAML approve: is an intended feature. This report is not claiming that workflow-level approval is inherently unintended.

The unintended behavior is that the recipe dangerous-tool policy exposes an operator-facing explicit override, allow_dangerous_tools=True, but a recipe can avoid that policy by moving the dangerous tool declaration from TEMPLATE.yaml requires.tools into the steps workflow. The recipe still runs through the standard recipe runner path, and the same workflow can self-approve the critical tool.

This conflicts with the documented safety model:

• PraisonAI's approval docs describe approval as pausing an agent before a risky tool and asking a human or configured channel to allow or deny it.
• The SDK approval docs describe a human-in-the-loop approval system for dangerous tool operations.
• Security-environment documentation describes opt-in access for potentially dangerous operations and secure defaults for RCE prevention.
• Policy-engine documentation describes policies that block dangerous operations and require approval for sensitive actions.

A control recipe that declares requires.tools: [execute_command] is denied with:

Tool 'execute_command' is denied by default. Use allow_dangerous_tools=True to override.

The bypass recipe uses the same tool but omits it from requires.tools; it passes policy and reaches the recipe runner's dry-run state.

PoV

Run:

python3 poc/poc.py

Expected output:

{
  "ok": true,
  "control_policy": "Tool 'execute_command' is denied by default. Use allow_dangerous_tools=True to override.",
  "control_recipe_status": "policy_denied",
  "bypass_policy": null,
  "bypass_recipe_dry_run_status": "dry_run",
  "workflow_approve_tools": [
    "execute_command"
  ],
  "runner_tool_names": [
    "execute_command"
  ],
  "command_stdout": "poc",
  "operator_env_auto_approve": null
}

The PoV creates two temporary recipes:

1. A control recipe with TEMPLATE.yaml requires.tools: [execute_command].…