Policies and guardrails

Two mechanisms act on a call before it reaches a model: invocation policies decide which product, how large an answer, how much spend; guardrail packs inspect what is in the request. Both run inside admission, before any reservation — a refused call is never charged, dispatches nothing to a provider, and leaves no usage record.

Invocation policies#

An invocation policy is a named rule owned by your organization. Its parts:

• Name and an active flag — an inactive policy stays listed but restricts nothing.
• Optional project scope (projectId) — without one, the policy applies to the whole organization.
• allowedModels — an allowlist of products.
• maxOutputTokens — a cap on requested output size.
• dailyMicro / monthlyMicro — spending ceilings in micro-USD.
• Guardrail packs and a content mode — below.

Policies do not override each other. Every active policy that applies to a call stays in force: allowlists intersect, every ceiling is checked, and the strictest guardrail mode wins. A call that satisfies one policy can still be refused by another.

Who can do what. Every member of the organization can read the policy list — you never have to guess whether a restriction applies to you. Only the organization Owner can create, edit, disable or delete one. Every change is audited, and enable/disable is a deliberate act with its own audit event, so a lifted restriction is visible as lifted rather than silently gone.

Guardrail packs#

A policy can compose up to three content packs, screened against the text of user messages only:

• pii — email addresses, phone numbers, payment-card numbers (Luhn-checked) and Thai national ID numbers
• secrets — AWS access key IDs, private-key blocks, bearer tokens and high-entropy tokens
• injection — instruction-override phrasing, system-prompt exfiltration attempts, and jailbreak/tool-abuse patterns

Each policy sets a content mode, and where policies overlap the strongest applicable mode wins per pack:

Three properties matter when you rely on them:

• Fail closed. Screening runs inside the admission transaction. If policy evaluation cannot complete, the call is not admitted — never waved through unchecked.
• Blocked content is never echoed back. The refusal says a guardrail matched, not what matched. The audit trail stores rule counts, not the matched text.
• Blocking happens before money moves. No reservation is taken, no provider is called, no usage record is created; the refusal is recorded as an invocation.denied audit event.

What a caller sees#

None of these are transient — retrying the identical request will fail identically. Backoff is the wrong response; change the call or ask the Owner to change the policy.

Next#

• Caps and spend controls — the ceilings and key limits in detail
• Errors — the full code list and what clears each