feat: tool-result scanning for langchain / openai-agents / genkit / l…

[scotty595]

…lamaindex (0.15.0)

0.14 wired tool-result scanning into the Mastra processor + MCP adapter only. 0.15 rolls the same protection out to the four other adapters that already do tool wrapping at construction time:

• LangChain — wraps tool.invoke (both governTool and governTools)
• OpenAI Agents — wraps tool.invoke AND tool.execute
• Genkit — wraps tool.call
• LlamaIndex — wraps tool.call

Each adapter gains a createResultScanner closure (factory bound to governance instance + agentId + config) and the existing wrapTool calls the new closure between await tool.invoke/call/execute(args) and the audit + return. The scanner runs scanToolResult at stage tool_result; on block the redacted detail object replaces the output before it reaches the agent loop.

Each config gains:
scanToolResults?: boolean // default true, opt-out via false
toolResultInjectionThreshold?: number // local detection threshold, default 0.5

What didn't change in 0.15:

• Anthropic / Mistral / Ollama — caller-driven handleToolUse pattern; tool-result scanning has to be integrated at the call site.
• Vercel AI — no tool-wrapping path on this adapter; follow-up needed.
• Bedrock — entry-gate only; AWS executes tools internally.
• Mastra middleware adapter (mastra.ts, not the processor) — different wrap shape; coverage to follow.

Drop-in upgrade. No public type breakage. Tests that mock tool returns may need scanToolResults: false to skip the helper.

1,372 tests, 0 failures.

Description

Checklist

• npm test passes (all 945+ tests)
• npm run build compiles clean
• No any types introduced
• All new files < 300 LOC
• Documentation updated (if public API changed)
• Tests added for new functionality

---

Note

Medium Risk
Changes the runtime behavior of multiple tool adapters by altering tool return values (including serializing/redacting on block), which could affect downstream expectations and tests even though the API surface change is additive.

Overview
Adds default-on tool-result scanning to the LangChain, OpenAI Agents, Genkit, and LlamaIndex adapters by wrapping each tool’s invoke/call/execute to run its returned value through scanToolResult() at stage tool_result, returning a redacted { blocked, reason, ruleId } object on block/approval so poisoned tool output never reaches the next LLM turn.

Each adapter config gains scanToolResults?: boolean (opt-out) and toolResultInjectionThreshold?: number; OpenAI Agents also stringifies blocked objects for the Responses API, LlamaIndex coerces ruleId to a non-null string for JSONValue compatibility, and LangChain guards non-object tool inputs when passing args into result scanning. Version bumps to 0.15.0 and the changelog documents the new behavior and migration notes.

^{Reviewed by Cursor Bugbot for commit 276e651. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 276e651. Configure here.}

[cursor]

LangChain scanner omits agentLevel causing false blocks

Medium Severity

The LangChain createResultScanner does not pass agentLevel to scanToolResult, while createEnforcer uses the real result.level from agent registration. The agent_level condition evaluator defaults missing agentLevel to 0, so agents registered at level ≥ 1 will be treated as level 0 during tool-result scanning. This causes agent_level rules to produce false-positive blocks on tool results for trusted, higher-level agents that correctly pass pre-execution enforcement.

Additional Locations (2)

• packages/governance/src/plugins/langchain.ts#L249-L250
• packages/governance/src/plugins/langchain.ts#L302-L303

 

^{Reviewed by Cursor Bugbot for commit 276e651. Configure here.}