I've been migrating our internal audit workflow from a custom Python orchestrator to LangGraph over the last few weeks. While the development velocity is fantastic, I'm stepping back and realizing our potential attack surface has expanded in ways I didn't fully anticipate at first.

My main concerns are about data flow and state persistence:

* **Checkpointing to External Stores:** The automatic checkpointing is powerful for resilience, but we're serializing the entire state object. If that state contains PII or sensitive intermediate reasoning, and we're using a shared Redis instance, that's a new data leakage risk we didn't have with our simpler, in-memory system.
* **Tool Node Permissions:** In our old system, each "tool" was a tightly-scoped function. With LangGraph, it's easy to bind a tool to an LLM call that has broader network access. A misconfigured node could theoretically call internal APIs it shouldn't, and that call would be logged as a normal step in the trace.
* **LangSmith by Default:** The telemetry is incredibly useful for debugging, but it means prompts, responses, and the graph state are leaving our perimeter unless we explicitly disable it or run the proxy. Our custom setup had zero external calls unless we coded it.

Here's a snippet of our current state schema that made me pause:

```python
class AuditState(TypedDict):
user_query: str # Could contain sensitive info
sql_results: list # Often holds raw DB rows
analysis: str
findings: list
# This whole dict gets checkpointed.
```

**My question to the group:** How are you handling this? Are you encrypting checkpoints? Using strict node-level policy? I'm particularly interested in policy-as-code approaches that could validate graph definitions *before* they run, ensuring no node uses tools outside an allow-list. OpenClaw's "guardrails as code" philosophy feels like it should apply here, but I'm still mapping the concepts over.