Skip to main content
A realistic health-tech use of the ai-agent template: a LangGraph prior- authorization graph runs on the host, but two sensitive steps hop into Declaw sandboxes under different SecurityPolicy postures:
  1. Payer clearinghouse submitpython sandbox, untrusted third-party payer API, egress locked to the payer domain only.
  2. Appeal-letter draft (GPT-4.1)ai-agent sandbox. PHI covered by the built-in detectors (ssn, credit_card, email, phone, person_name) is redacted on outbound, OpenAI sees [REDACTED_*] tokens, then Declaw rehydrates the originals in the response so the letter your agent reads back contains the real values. (member_id has no built-in detector — see the custom-regex note below.)
This is a distilled version of health-tech/sandboxed/01-prior-auth-langgraph/run.py. Two sandboxes, two policies, one graph.
The appeal-draft step spends real OpenAI credits — one pass against gpt-4.1 costs roughly 0.050.05–0.15. Set OPENAI_API_KEY before running.

What you’ll learn

  • Running a LangGraph workflow on the host while sandboxing only the steps that touch untrusted inputs or external LLMs
  • Using two different SecurityPolicy objects in one workflow — loose for the clearinghouse, LLM-grade for the GPT-4.1 appeal
  • Using rehydrate_response=True so the agent code is oblivious to the redact/rehydrate round-trip — it sees original PHI in the letter, while OpenAI only ever saw tokens

Prerequisites

Code

Expected output (shape)

The key thing to notice in the letter: the patient’s name is present in cleartext, even though OpenAI only ever saw a [REDACTED_PERSON_NAME] token. rehydrate_response=True on the appeal sandbox’s PIIConfig restores the original from the outbound-redaction token before the response body is handed back to the agent code. (The MBR-7781432 member ID in this example is not one of the built-in PII entities and passes through as-is — see the note below on custom regex rules for payer identifiers.)

What Declaw is doing behind the scenes

  • Two SecurityPolicy objects, two trust postures. The payer-clearinghouse sandbox allows only *.payer-clearinghouse.com outbound and redacts PHI without rehydrating (you don’t trust the payer’s response). The appeal sandbox allows only api.openai.com + PyPI bootstrap and rehydrates responses (you do trust OpenAI not to be storing the tokens).
  • PII scanner runs on every outbound request body in either sandbox. The built-in entity set is ssn, credit_card, email, phone, person_name, and ip_address — it catches several of the 45 CFR §164.514(b) Safe Harbor identifiers, but not all of them (there is no built-in detector for addresses, member IDs, or other payer-specific formats). For HIPAA Safe Harbor de-identification you must add the remaining identifiers yourself. Member IDs (e.g. MBR-7781432) and street addresses are examples — add a custom regex via a transformation rule to redact and rehydrate them alongside the built-in entities.
  • Rehydration is a proxy-side feature — the VM process sees original PHI in the response bytes exactly as OpenAI sent tokens back. No agent code change is required.
For agent-in-sandbox (instead of host LangGraph + sandboxed steps), swap the host-side graph for one running entirely inside a single ai-agent sandbox — same policies, just one longer-lived sandbox. See Agent-in-Sandbox → Fully Secured.