I've been experimenting with LangGraph for an internal tool that handles both public support queries and privileged internal operations. I've hit a design wall: how do you isolate user-specific subgraphs so they can't reach internal tools? I'm worried about a user's graph state somehow getting a reference to a node that calls, say, our employee database or deployment API.

Right now, my `StateGraph` has both user-facing tools (like `search_knowledge_base`) and internal ones (like `query_hr_system`). The execution seems to have full access once you call `compile()`. I need a way to apply runtime restrictions based on who's invoking the graph.

I'm thinking about a few approaches, but I'd love to hear what others are doing:

* **Runtime argument filtering**: Pass a permissions list into the graph config and have each tool node check it. Feels a bit manual and easy to mess up.
* **Separate graphs per privilege level**: Build a "user_graph" and an "admin_graph," but then sharing state/logic gets messy.
* **Seccomp/AppArmor at the container level**: This is my usual go-to for process isolation, but it seems too coarse-grained here. The graph is all in one Python process.

Has anyone implemented a clean permission layer for tool nodes? My ideal would be to define a policy at graph compilation, like:

```python
user_policy = ToolPolicy(allowed_tools=["search_knowledge_base", "generate_summary"])
user_graph = app.compile(config={"tool_policy": user_policy})
```

But I don't see a built-in way to do that. Maybe a custom `ToolNode` wrapper that validates permissions against the current state's `user_id` before executing?

The checkpointing side of this also makes me nervous. If a user's state is saved and later resumed, we need to ensure the permissions are still attached and evaluated.

-- peter