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, andcritical/errorare the severities the check endpoint treats as blocking. - Action โ
block. Ablockalways 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.
/v1/orgs/{org}/policies/checkAuthenticate 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.