Write your first policy

This guide walks you through a concrete first policy: block AWS access keys from leaking through your AI traffic. You'll build it in the dashboard, enable it on a gateway in Strict mode, and confirm it fires โ€” both through the gateway and via the check endpoint. For the full model behind policies (rule types, severities, actions, scopes, and enforcement modes), see Policies.

Note

A secrets rule needs zero configuration โ€” the engine ships built-in detectors for AWS keys, GitHub tokens, JWTs, and more. You're mostly naming the policy and wiring it to a gateway.

1. Open the policy editor

In the dashboard, go to Policies and click Create Policy. You land on the New Policy form.

2. Name the policy

Fill in the top panel:

  • Name โ€” Block AWS keys (required).
  • Description (optional) โ€” Catch leaked AWS access key IDs in prompts and responses.
  • Enabled โ€” leave the toggle on so the policy is live once saved.

3. Add a secrets rule

Click Add Rule and pick a rule type. The built-in secrets detector is what catches AWS keys with no further setup โ€” it recognizes the AKIA... access key ID format automatically, along with other common credentials.

Tip

Reach for a pattern rule (a literal forbidden substring) or a regex rule (your own expression) when you need to ban something org-specific, like an internal hostname. For credentials and PII, the built-in secrets and pii rules already cover the common cases.

4. Set severity, action, and scope

Configure how the rule behaves:

  • Severity โ€” critical. AWS keys are a hard fail, and critical/error are the severities the check endpoint treats as blocking.
  • Action โ€” block. A block always wins when multiple rules fire.
  • Scope โ€” both. Catch keys on the way in (ingress, the prompt your tool sends) and on the way out (egress, the model's response).

5. Save the policy

Click Create Policy. You're returned to the Policies list, where the new policy appears with its enable toggle on.

Warning

Saving and enabling a policy makes it detectable, but the enforcement mode lives on the gateway, and unset modes fail open to Passive โ€” they log but never block. To actually block, you must pin Strict on the gateway in the next step.

6. Enable it on a gateway in Strict mode

Go to Gateways, open the gateway your tools point at, and reference the Block AWS keys policy. Set its enforcement mode to Strict so an input violation returns HTTP 403 and the upstream model is never called. (Start with Passive if you'd rather observe first, then promote to Strict once you've seen what it catches.)

7. Verify it fires

Send a request through the gateway containing a fake AWS key. Use AWS's documented example value, AKIAIOSFODNN7EXAMPLE, so you never paste a real credential.

curl https://gateway.unyform.ai/gw/<gateway-id>/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "claude-sonnet-4-6", "max_tokens": 256,
       "messages": [{"role": "user",
         "content": "Store this key in config: AKIAIOSFODNN7EXAMPLE"}]}'
{
  "error": {
    "type": "policy_violation",
    "message": "Blocked by policy: AWS Access Key ID detected"
  }
}

Behavior depends on the enforcement mode pinned on the gateway:

  • Strict โ€” the gateway returns HTTP 403 and never calls the model.
  • Active โ€” the request continues, but a corrective system message is injected so the model self-corrects.
  • Passive โ€” the request passes through unchanged; the violation is only logged.

8. Or test content directly with the check endpoint

You don't have to make a full model call to confirm a policy works. The check endpoint evaluates submitted text against every enabled policy for your org and returns a verdict โ€” handy for pre-commit hooks and CI gates.

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",
  "matched_policies": ["Block AWS keys"]
}

allowed is false whenever a matched violation is critical or error severity โ€” exactly the critical you set in step 4. warning and info matches still appear in matched_policies but don't block.

9. Check the audit log

Detection is audited regardless of enforcement mode, so even a Passive policy leaves a trail. Open Dashboard โ†’ Audit and find the request: you'll see which policy fired, at what severity, and what the gateway did about it. The matched secret is masked in the record (e.g. AKIA...MPLE), so the audit trail never stores the raw value.

Tip

Next, broaden coverage: add a pii rule to the same policy to catch personal data, or activate a Policy Template Pack from the Policies page to seed a set of security rules at once.

Edit this page on GitHub