Policies

A policy is an org-defined rule the gateway evaluates against AI traffic. It runs on the way in (the request your tool sends) and on the way out (the model's response), looks for things like leaked secrets, PII, or forbidden patterns, and reacts according to how you've configured it — log, nudge the model, or hard-block.

Policies are the enforcement layer of governance. Blueprints and idioms shape generation by feeding the model your conventions; policies catch what slips through anyway. The two are complementary: context makes good output likely, policies make bad output visible.

Note

Policies detect violations regardless of mode. The enforcement mode only decides what happens after a match — detection always runs and is always audited.

Anatomy of a policy

Each policy is a named set of rules with a type, a severity, a scope, and an action. The policy engine ships four rule types:

Type	What it matches
`secrets`	Built-in detectors for credentials — AWS keys, GitHub tokens, JWTs, bearer tokens, Stripe/Slack keys, private keys, DB connection strings, password/secret assignments
`pii`	Built-in detectors for personal data — SSNs, email addresses, US phone numbers, credit card numbers, IPv4 addresses
`pattern`	A literal substring you forbid (e.g. `DROP TABLE`), with an optional custom message
`regex`	A custom regular expression you supply, with an optional custom message

Every match produces a violation carrying the policy name, a severity, a human message, and the matched text (secrets and PII are masked — long...alue — so the audit trail never stores the raw value).

Severities are critical, error, warning, and info. Actions are allow, block, and redact. When several policies fire on one request, a block always wins — it is never downgraded by a redact or allow from another rule.

Tip

Built-in secrets and pii rules need no configuration — point a policy at them and you immediately catch the most common leaks. Reach for pattern and regex for org-specific bans like internal hostnames, deprecated APIs, or TODO markers you don't want shipped.

Where policies run

The gateway evaluates policies at two points in the request path. Input policies see the user's request text before it reaches the model; output policies see the model's response before it returns to your tool. A policy's scope (ingress, egress, or both) controls which point it applies to.

sequenceDiagram
    participant CC as Claude Code / SDK
    participant GW as Unyform Gateway
    participant AN as Anthropic API
    CC->>GW: request (your API key)
    GW->>GW: evaluate INPUT policies (ingress)
    alt Strict + violation
        GW-->>CC: 403 with violation details
    else Pass / Active / Passive
        GW->>AN: forward (BYOK)
        AN-->>GW: response / SSE stream
        GW->>GW: evaluate OUTPUT policies (egress)
        GW-->>CC: response + audit entry
    end

This wiring is the same on the OpenAI-compatible chat path and the native Anthropic passthrough path. On passthrough, policies run best-effort on text extracted from the raw request and response — request and response shapes are forwarded verbatim, but governance and audit still apply.

What happens on a violation

Detection is constant; the enforcement mode decides the reaction. Modes are set per policy, per gateway:

Passive (the default for new gateways)

Log the violation and pass the request through unchanged. This is observability-only — nothing is blocked, but every match lands in the audit trail. Start here when rolling out a new rule to see what it would catch.

Active

Inject a corrective system message so the model self-corrects, then continue. The request is not rejected; the model is told what it got wrong and given a chance to fix it on the next turn.

Strict

Reject immediately. An input violation returns HTTP 403 with the violation details and the upstream model is never called; an output violation blocks the response from reaching your tool. This is the hard block.

Warning

Unknown or unset enforcement modes fail open — they default to Passive. A misconfigured policy logs but never blocks, so verify Strict is actually set on the rules you rely on to gate traffic.

Either way, the violation is recorded and visible in audit alongside the request, so you can see exactly which policy fired, at what severity, and what the gateway did about it.

Managing policies in the dashboard

Policies live under Dashboard → Policies. Each policy has an enable toggle — flip it off to retire a rule without deleting it — and a per-rule editor where you add secrets, pii, pattern, or regex checks. Gateways then reference policies and pin each one's scope and enforcement mode, so the same rule can run Passive on one gateway and Strict on another.

Note

Some rule types you see in the editor (file-required, dependency-forbidden, blueprint-required, and similar) are analysis-time checks evaluated elsewhere, not at the gateway. The gateway silently skips them during live request evaluation and applies only the four runtime rule types above.

Checking content directly

You don't have to route through a full chat request to test content against your org's policies. The check endpoint evaluates submitted text against every enabled policy for your org and tells you whether it would be allowed.

POST/v1/orgs/{org}/policies/check

Authenticate with your org's API key (bearer token). The body takes an action label and the content to evaluate:

curl https://gateway.unyform.ai/v1/orgs/<org-id>/policies/check \
  -H "Authorization: Bearer $UNYFORM_API_KEY" \
  -H "content-type: application/json" \
  -d '{"action": "commit", "content": "AKIAIOSFODNN7EXAMPLE"}'

{
  "allowed": false,
  "reason": "AWS Access Key ID detected: aws_access_key",
  "matched_policies": ["no-secrets"]
}

allowed is false when any matched violation is critical or error severity; warning and info matches surface in matched_policies but do not block. Use it in pre-commit hooks, CI gates, or any place you want a policy verdict without making a model call.

Edit this page on GitHub

← Idioms & drift Context injection →