Guardrails

// POST /api/policies   (session auth)
{
  "name": "block-gpt-4-for-interns",
  "description": "Interns can't use the expensive tier",
  "effect": "deny",
  "reason": "gpt-4.1 is not available to the intern team",
  "match": {
    "team_ids": ["<intern-team-uuid>"],
    "models": ["gpt-4.1"]
  },
  "enforcement": "enforce",
  "enabled": true
}

​

Fields

​

The effects

• deny — the request is blocked with 403 before dispatch. No provider call, no charge.
• flag — the request proceeds normally. The match is recorded in the decision log for visibility, with no effect on the response.
• require_approval — not available yet. The intent is that the request is blocked with 403, an approval request opens against the effect’s approval policy, and the caller retries once it’s granted. What isn’t settled is the grant itself: what an approval records so the retry passes. Until an ADR specifies that, authoring the policy returns 422 rather than leaving you with a rule that denies forever and reports “approval required”.

​

Testing before you enforce

• Set enforcement: "shadow" on the policy itself — it evaluates on every real request and logs the decision, but never denies or gates one.
• POST /api/policies/{id}/shadow-impact — run a policy against recent traffic on demand to see its hit rate before flipping it to enforce.

​

Where next