---
id: GHSA-v847-hxxw-3pxg
title: PraisonAI recipe.run_stream skips dangerous-tool policy enforcement
summary: PraisonAI recipe.run_stream skips dangerous-tool policy enforcement
severity: high
cvss: 7.8
cwe:
  - CWE-78
  - CWE-693
  - CWE-863
vendor: praisonai
product: praisonai
ecosystem: pip
affected:
  - 'praisonai >= 4.5.87, <= 4.6.58'
patched:
  - praisonai 4.6.59
published: '2026-06-18'
updated: '2026-06-18'
source: GHSA
sourceUrl: 'https://github.com/advisories/GHSA-v847-hxxw-3pxg'
references:
  - url: >-
      https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-v847-hxxw-3pxg
  - url: 'https://github.com/advisories/GHSA-v847-hxxw-3pxg'
tags:
  - ghsa
  - pip
ingestedAt: '2026-06-29T14:31:46.977Z'
---

## Overview

# PraisonAI `recipe.run_stream()` skips dangerous-tool policy enforcement

## Summary

PraisonAI recipe execution blocks default-denied dangerous tools unless the
caller explicitly passes `allow_dangerous_tools=True`. The normal `recipe.run()`
path enforces this with `_check_tool_policy()`. The streaming path,
`recipe.run_stream()`, loads the same recipe, checks dependencies, and then
calls `_execute_recipe()` without running the dangerous-tool policy check.

As a result, a recipe that honestly declares `execute_command` in
`TEMPLATE.yaml requires.tools` is denied by `recipe.run()`, but reaches the
execution engine through `recipe.run_stream()` with
`allow_dangerous_tools=False`.

The local PoV uses a harmless `printf` canary, explicitly unsets
`PRAISONAI_AUTO_APPROVE`, and avoids network access.

## Affected Product

- Repository: `MervinPraison/PraisonAI`
- Package: `praisonai`
- Components:
  - `src/praisonai/praisonai/recipe/core.py`
  - `src/praisonai/praisonai/recipe/serve.py`
  - `src/praisonai/praisonai/cli/features/recipe.py`
  - `src/praisonai-agents/praisonaiagents/workflows/yaml_parser.py`
  - `src/praisonai-agents/praisonaiagents/workflows/workflows.py`

Validated affected:

- current main `2f9677abb2ea68eab864ee8b6a828fd0141612e1`
  (`v4.6.57-4-g2f9677ab`)
- `v4.6.57`
- `v4.6.56`
- `v4.6.10`
- `v4.6.9`
- `v4.5.128`
- `v4.5.120`
- `v4.5.96`
- `v4.5.87`

Suggested affected range: `>= 4.5.87, <= 4.6.57`.

PyPI lists `PraisonAI 4.6.57` as the latest release on 2026-06-13.

Earlier tested tags through `v4.5.85` failed in this source checkout before the
tested workflow path due an unrelated `praisonaiagents.output.models` import
error. They are not claimed fixed or unaffected.

## Root Cause

`recipe.run()` enforces the dangerous-tool gate:

```python
if not options.get("allow_dangerous_tools", False):
    policy_error = _check_tool_policy(recipe_config)
    if policy_error:
        return RecipeResult(..., status=RecipeStatus.POLICY_DENIED, ...)
```

`recipe.run_stream()` has a sibling execution path. It loads the recipe and
checks dependencies, but then goes directly to execution:

```python
recipe_config = _load_recipe(name, offline=options.get("offline", False))
...
output = _execute_recipe(recipe_config, merged_config, session_id, options)
```

There is no equivalent `_check_tool_policy()` call in `run_stream()` before
execution or before the dry-run shortcut.

The CLI exposes this path via `praisonai recipe run <recipe> --stream`, and the
recipe HTTP server exposes it as `POST /v1/recipes/stream`.

## Why This Is Not Intended Behavior

The normal recipe path clearly treats declared dangerous tools as denied by
default. A control recipe with `TEMPLATE.yaml requires.tools:
[execute_command]` returns:

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

That operator-facing override should not depend on whether the caller requests
streaming output. PraisonAI's own docs describe approval as requiring a human
or configured channel before risky tools run, describe security environment
variables as opt-in access for dangerous operations with secure defaults, and
describe policy controls as blocking dangerous operations.

This is distinct from the prior report `PRAI-CAND-011`:

- `PRAI-CAND-011` covers workflow tool declarations that are omitted from
  `TEMPLATE.yaml requires.tools`.
- This report covers a sibling entrypoint that skips the policy check even when
  `TEMPLATE.yaml` correctly declares the dangerous tool.

It is also distinct from the published Recipe-server authentication fail-open
advisory. That advisory covers missing authentication secrets. This report
assumes the attacker has whatever access is already needed to invoke recipe
streaming and focuses on the missing dangerous-tool policy guard.

## Local PoV

Run:

```bash
python3 poc/pov_prai_cand_012_stream_policy_bypass.py
```

Expected output includes:

```json
{
  "ok": true,
  "policy_error": "Tool 'execute_command' is denied by default. Use allow_dangerous_tools=True to override.",
  "control_recipe_status": "policy_denied",
  "execution_reached": [
    {
      "recipe": "declared-dangerous-stream",
      "declared_required_tools": ["execute_command"],
      "allow_dangerous_tools": false
    }
  ],
  "workflow_approve_tools": ["execute_command"],
  "runner_tool_names": ["execute_command"],
  "command_stdout": "PRAI-CAND-012-CANARY",
  "operator_env_auto_approve": null
}
```

The PoV creates a temporary recipe that declares `execute_command` in
`TEMPLATE.yaml requires.tools`.

Control:

- `recipe.run(..., options={"force": True})` returns `policy_denied`.

Bypass:

- `recipe.run_stream(..., options={"force": True})` emits the `executing`
  event and reaches `_execute_recipe()` while `allow_dangerous_tools` remains
  false.
- The same recipe workflow resolves `execute_command` and preserves
  `approve: [execute_command]`.
- With the workflow approval context installed, the resolved tool runs the
  harmless local command `printf PRAI-CAND-012-CANARY`.

The PoV monkey-patches `_execute_recipe()` only to prove that
`run_stream()` crosses the policy boundary without invoking an LLM. The command
canary is executed directly through the same resolved workflow tool and
approval context to keep the proof deterministic and local-only.

## Impact

If an operator runs an untrusted recipe through streaming mode, or exposes the
recipe streaming API to users who can choose recipe names or URIs, the recipe
can reach execution with default-denied tools even though the caller did not
set `allow_dangerous_tools=True`.

If the workflow reaches the approved `execute_command` tool call, commands run
with the privileges of the PraisonAI process. The exact trigger depends on the
workflow and model/tool-call path, but the dangerous-tool policy boundary is
already bypassed before execution.

The HTTP recipe sidecar is documented as a localhost REST API with SSE
streaming and optional API-key/JWT authentication. This report does not claim
default unauthenticated network RCE. In authenticated or exposed sidecar
deployments where lower-trust users can invoke `/v1/recipes/stream`, the same
policy gap can become a remote recipe-execution issue.

## Suggested Fix

Centralize recipe preflight enforcement so every execution mode uses the same
guard:

1. Run `_check_tool_policy(recipe_config)` in `run_stream()` unless
   `options["allow_dangerous_tools"]` is true.
2. Perform that check before both dry-run and real execution, matching
   `recipe.run()`.
3. Prefer a shared helper for dependency checks, dangerous-tool policy checks,
   and dry-run handling so future entrypoints cannot drift.
4. Add regression tests:
   - declared dangerous tool is denied by `recipe.run()`;
   - the same declared dangerous tool is denied by `recipe.run_stream()`;
   - `allow_dangerous_tools=True` preserves the intended opt-in behavior;
   - `/v1/recipes/stream` maps a policy denial to a non-success SSE event or
     equivalent HTTP failure.

## Affected packages

- `praisonai >= 4.5.87, <= 4.6.58`

## Remediation

Upgrade to a patched release:

- `praisonai 4.6.59`