Feedback wanted: automatic fail-closed guard before langgraph_bigtool.create_agent()

OSS Product Help LangGraph
1

Hi everyone,

I’m looking for feedback from LangGraph/LangChain users on a small Python experiment called DHMS AgentFuse.

The idea is narrow:

DHMS is an automatic fail-closed execution fuse for side-effect-capable agent tools.

A LangChain / LangGraph tool may be a simple local callable, or it may wrap something that can produce external side effects: SQL mutation, database writes, file mutation, network calls, provider/model API calls, code execution, browser actions, messaging actions, GitHub/Jira/Slack actions, and so on.

Existing HITL / interrupt patterns are useful when a human should review, approve, edit, or reject a proposed action.

DHMS explores a stricter default for known risky tool capabilities:

Fail closed automatically before protected payload execution, and produce evidence that the protected payload body did not run.

Human review could still exist later, but as an escalation or override path rather than the default safety mechanism.

I tested this against langgraph-bigtool because its API exposes a natural tool registry boundary.

The current demo wires into the real langgraph_bigtool.create_agent() API:

from langgraph_bigtool import create_agent

guarded_tool_registry = {
    tool_id: dhms_guard(tool)
    for tool_id, tool in original_tool_registry.items()
}

builder = create_agent(
    llm,
    guarded_tool_registry,
    retrieve_tools_function=retrieve_tools,
)

The retrieval function is deterministic:

def retrieve_tools(query: str) -> list[str]:
    return list(guarded_tool_registry.keys())

What the demo proves:

  • DHMS imports and uses the real langgraph_bigtool.create_agent API.

  • DHMS builds a guarded tool registry before create_agent().

  • The guarded registry is passed into the real agent builder.

  • A safe read-only tool becomes RELEASE_CANDIDATE.

  • A SQL mutation tool fails closed as sql_mutation.

  • A model/provider API request tool fails closed as model_api.

  • Protected payload bodies are not executed.

  • The demo does not compile, invoke, or stream the graph.

  • The demo does not call providers, networks, databases, SQL, credentials, or user data.

This is not a production runtime claim. It is a deterministic pre-tool boundary experiment.

The safety claim is intentionally narrow:

Known side-effect-capable tools should fail closed before protected payload execution, with evidence that the protected payload body did not run.

My questions:

  1. Is the tool registry / agent-builder boundary a useful place to guard risky tools?

  2. Would you prefer this kind of guard at the registry boundary, inside a ToolNode / middleware layer, or somewhere else?

  3. Is “automatic fail closed before protected payload execution” a useful safety contract for agent tools?

  4. Would you use this as a complement to HITL, where obvious risky capabilities fail closed automatically and only exceptions escalate to human review?

  5. What would you expect before considering this production-useful: live graph invocation demo, middleware integration, PyPI package, policy config, audit logs, or something else?

Repo/demo: [ GitHub - MkaliezZ/dhms-engine: DHMS: An agent execution safety and control kernel - an execution fuse protocol for AI agents - built from memory/context/tool-state perturbation testing toward runtime execution control. · GitHub ]

I’d appreciate critical feedback, especially from anyone building agents with large tool registries or tools that can perform external side effects.

4

Small clarification:

This demo does not compile, invoke, or stream the LangGraph agent.

It only tests the tool_registry → create_agent() wiring boundary.

The safety claim is intentionally narrow:

known side-effect-capable tools fail closed before protected payload execution, and the demo records that protected payload execution count stayed zero.

It does not claim production runtime protection yet.

5

One specific design question I’m trying to validate:

For LangGraph agents with tools that can mutate SQL, files, APIs, tickets, messages, or other external systems, where do you usually enforce tool safety?

  • before tools enter the registry / agent builder

  • when tools are retrieved or resolved

  • inside ToolNode right before execution

  • through HITL / interrupts

  • through a simple tool-name allowlist

I got one useful comment elsewhere that ToolNode-level whitelisting is straightforward today, while registry-level guarding is cleaner but gets tricky with dynamic tools.

I’m especially curious how LangGraph users handle dynamic tools or state-dependent tool permissions.