Loading…
Open-Policy Exchange
~5 min to deploy
LangChain Regulated-Data RAG Gate
Gates retrieval and external API calls that touch regulated records — restricted subjects never leave the boundary.
For: Teams running RAG or external API calls over regulated customer data
HIPAA §164.312(a)SOC 2 CC6.1ISO 27001 A.5.34
What it enforces
Restricted-subject block
Blocks retrieval or action on a customer marked restricted.
Purpose-limitation check
Restrains a retrieval whose declared purpose is not on the approved list.
External-egress escalation
Escalates any call that would send regulated fields to a host outside the boundary.
langchain-regulated-data-rag-gate.yaml
# LangChain Regulated-Data RAG Gate
# Fork: set approved_purposes and boundary_hosts for your environment.
apiVersion: decionis.dev/v1
kind: PolicyPack
metadata:
name: langchain-regulated-data-rag-gate
surface: langchain
workflow_key: regulated_retrieval
standards: [HIPAA-164.312, SOC2-CC6.1, ISO27001-A.5.34]
defaults:
mode: shadow
emit_dossier: true
approved_purposes: [care_coordination, billing_support, member_service]
boundary_hosts: ["internal.records.local"]
rules:
- name: restricted_subject_block
when: "tool in ['retrieve', 'lookup_customer']"
decision: |
BLOCK IF subject.restricted == true
ALLOW OTHERWISE
reason_code: restricted_subject
- name: purpose_limitation_check
when: "tool == 'retrieve'"
decision: |
RESTRAIN IF request.purpose not in approved_purposes
ALLOW OTHERWISE
reason_code: purpose_not_approved
- name: external_egress_escalation
when: "tool_call.egress_host != null"
decision: |
ESCALATE IF payload.contains_regulated_fields == true AND tool_call.egress_host not in boundary_hosts
ALLOW OTHERWISE
reason_code: regulated_data_leaving_boundary
Fork it, change the thresholds to match your environment, and deploy in shadow mode first — it defaults to listen-only so nothing in your live pipeline changes.
How to install it
Wraps any LangChain BaseTool. The LLM still picks the tool on the same prompt; Decionis decides if the call fires.
LangChain (Python) — shadow mode
# pip install decionis-langchain
from decionis import DecionisClient
from decionis_langchain import DecionisGateTool
client = DecionisClient(api_key="...", base_url="https://api.decionis.com")
gated_refund = DecionisGateTool.wrap(
inner_tool=send_refund,
client=client,
tenant_id="org-uuid",
workflow_key="refund_execution",
shadow_mode=True, # ← every verdict recorded; inner tool always runs
site_base_url="https://decionis.com",
)
agent.bind_tools([gated_refund])
Ships in shadow mode — every verdict is recorded, nothing is blocked.
What to do next
This recipe is one step in a path. The same five steps apply to every recipe in the exchange.
- Simulate this recipe
Run the policy against a realistic action in the browser. Push it past what the rules allow and watch the verdict come back. No account.
- View the signed Decision Dossier
See exactly what was decided and why: the rule that fired, the evidence it read, the policy version in force, and an Ed25519 signature you can verify yourself.
- Deploy in shadow mode
Measure what the policy would have caught on your own traffic without touching the live path. Every recipe defaults to shadow, so the first deployment carries no execution risk.
- Connect a real workflow
Point the same policy at the system where the action actually originates — a checkout, an ERP posting, a Zap, an agent's tool call.
- Share the verified result
Publish the proof: a public verification link, an embeddable badge, a PR comment, or an anonymized shadow-mode finding. This is how the next person discovers Decionis.