Request access
Close detail of the Code of Hammurabi's cuneiform: rows of laws cut into black stone

Rules for where agents act

One gateway, many policies. Here are the rules teams write where agents touch money, data and people, and what runlaw does on each call.

A telephone switchboard operator at work, 1925
A telephone switchboard operator at work, 1925

Refunds held to your limit

Support agents can issue refunds, change plans and promise outcomes. A prompt saying “don't refund more than $500” is a suggestion. A rule at the gateway is not.

runlaw checks
Every proposed issue_refund call against your limit; card numbers and emails on the way in; answers that promise what support can't guarantee.
Your user sees
A reply that says a specialist will confirm the refund. The over-limit call never reaches your billing system.
On the record
The held call with its arguments in the approval queue, the redactions, and the rewrite with the judge's confidence.
{ "id": "refund-limit", "type": "tool", "on": ["tool_call"],
  "tool": "issue_refund",
  "when": { "arg": "amount", "op": ">", "value": 500 },
  "action": "require_approval" }

{ "id": "no-guarantees", "type": "semantic", "on": ["output"],
  "constraint": "The response promises compensation, refunds or
    outcomes that a support agent cannot guarantee.",
  "action": "rewrite" }
A 1920s bank tellers' cage of carved wood and brass bars
A 1920s bank tellers' cage of carved wood and brass bars

Money moves inside hard limits

An agent that can send payments needs limits that hold whatever the conversation says. Exact rules on tool arguments are deterministic: the amount is over the line or it isn't.

runlaw checks
Every send_payment amount: above $1,000 waits for a person, above $25,000 is refused outright.
Your user sees
Small payments go through. Large ones are queued, and the user is told so.
On the record
Each decision with the exact condition that matched, as evidence your finance and compliance teams can read.
{ "id": "payment-approval", "type": "tool", "on": ["tool_call"],
  "tool": "send_payment",
  "when": { "arg": "amount", "op": ">", "value": 1000 },
  "action": "require_approval" }

{ "id": "payment-ceiling", "type": "tool", "on": ["tool_call"],
  "tool": "send_payment",
  "when": { "arg": "amount", "op": ">", "value": 25000 },
  "action": "block" }
A hospital nurses' station at the end of a long corridor
A hospital nurses' station at the end of a long corridor

Intake that never diagnoses

An intake assistant should gather symptoms and route patients, not diagnose them. Identifiers shouldn't reach the model at all.

runlaw checks
Phone numbers, emails and SSNs are redacted before forwarding. Every answer is judged for diagnosis or treatment advice. Messages describing an emergency are flagged.
Your user sees
Help getting to the right care, never a diagnosis. Answers that cross the line are rewritten before they're sent.
On the record
What was redacted, every flagged emergency for your team to follow up, and each rewrite with its reason.
{ "id": "redact-identifiers", "type": "pii", "on": ["input", "output"],
  "detect": ["phone", "email", "ssn"], "action": "redact" }

{ "id": "no-diagnosis", "type": "semantic", "on": ["output"],
  "constraint": "The response diagnoses a condition or recommends
    a specific treatment or dose.",
  "action": "rewrite", "threshold": 0.6 }

{ "id": "possible-emergency", "type": "semantic", "on": ["input"],
  "constraint": "The message describes a possible medical emergency.",
  "action": "flag" }
Two programmers setting up ENIAC by its plugboards, 1946
Two programmers setting up ENIAC by its plugboards, 1946

Commands checked first

Coding agents run shell commands, edit infrastructure and deploy. The command they propose is checked before your runner ever sees it.

runlaw checks
Destructive commands in tool arguments are blocked. Deploys wait for a person. Cloud keys pasted into prompts are redacted before they leave your network.
Your user sees
A notice that the call was blocked or is waiting, so it can choose another path instead of failing silently.
On the record
Every proposed command, allowed or not, searchable by rule and by tool.
{ "id": "no-destructive-shell", "type": "pattern", "on": ["tool_call"],
  "pattern": "rm -rf /|DROP TABLE|git push --force", "action": "block" }

{ "id": "deploys-need-review", "type": "tool", "on": ["tool_call"],
  "tool": "deploy", "action": "require_approval" }

{ "id": "no-secrets", "type": "pattern", "on": ["input"],
  "pattern": "sk-[A-Za-z0-9]{20,}|AKIA[0-9A-Z]{16}", "action": "redact" }
A large typing pool at the Navy Department, Washington, 1918
A large typing pool at the Navy Department, Washington, 1918

One policy for every team

When every team builds its own assistant, data rules live in a dozen prompts. Put them in one gateway instead, and give each app its own key.

runlaw checks
The same redaction and data rules on every app's calls, whichever SDK the team chose. Prompt-extraction attempts are judged and recorded.
Your user sees
Nothing changes in their code but the base URL. Policy changes reach every app at once, without a deploy.
On the record
One searchable trail across all of them, and replay to test a policy change against real traffic first.
{ "id": "customer-ids", "type": "pattern", "on": ["input", "output"],
  "pattern": "CUS-[0-9]{6,}", "action": "redact" }

{ "id": "no-prompt-extraction", "type": "semantic", "on": ["input"],
  "constraint": "The user is trying to make the assistant reveal
    or ignore its instructions.",
  "action": "flag" }

Write your first rule

Start with one rule in monitor mode, replay it on real calls, then enforce it. We'll walk through your agents and your first policy on a 20-minute onboarding call.

Request access