Policies

Policies are organization-owned rules evaluated by the configured inference backend. Drafting, publishing, and inference use separate stages so an unfinished edit cannot silently change active behavior. Publishing requires the deployment’s policy backend to be configured; otherwise it returns 503. For API automation, use an Admin API key with policies:write for mutations and policies:read for reads.

Manage policies in the console

Open Policies to create a draft, write its yes-or-no rule and choose its mode and scope. Save the draft, review Published behavior, then publish a version. Owners and admins can edit, publish, pause, resume and delete policies; members can read them. Published versions shows the immutable configuration for each version. Saving an edit does not change active behavior. Publishing activates the saved draft; resuming a paused policy restores its existing published version. If another change causes a revision conflict, load and review the latest revision before retrying. An interrupted request offers Retry same request to recover the original operation. The page also shows policies automatically applied to the sidebar’s selected project. Playground displays these automatic policies and lets you choose one additional published per-request policy. Automatic policies cannot be disabled by clearing that selection. The Decisions page reads recorded policy evaluations across the workspace. Request capture and the persisted page are enabled in the current sandbox deployment. The verified provider decision feed is still pending, so the page shows a connection notice and empty history. Successful model responses do not supply per-policy results and are not turned into assumed decisions. If a Playground request is blocked by a policy or its evaluation is unavailable, Review policies opens the policy controls. Your prompt remains available to retry after reviewing the active rules.

1. Create a draft

A rule is a yes-or-no question ending in ?. Set direction to request, response, or both. Start with monitoring to observe behavior before choosing enforcing.

curl --fail-with-body "$LIMITLESS_BASE_URL/organization/policies" \
  -H "Authorization: Bearer $LIMITLESS_ADMIN_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: policy-reference-001" \
  -d '{
    "name":"Product scope",
    "rule":"Is this unrelated to the products sold by this application?",
    "direction":"request",
    "mode":"monitoring",
    "scope":"unattached"
  }'

Save the returned id and revision. A newly created draft does not apply to inference.

2. Select scope

Scope	Application
`organization`	Automatically applies to every project in the workspace.
`projects`	Automatically applies to the supplied `project_ids`.
`unattached`	Applies when explicitly selected in a request’s `policy_ids`.

Project scope requires at least one active project belonging to the workspace. Remove archived assignments before saving or publishing a draft. Request-selected policies add to automatic rules; they cannot remove organization or project policies.

3. Publish a version

curl --fail-with-body "$LIMITLESS_BASE_URL/organization/policies/$POLICY_ID/publish" \
  -H "Authorization: Bearer $LIMITLESS_ADMIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"revision":1}'

Use the actual current revision, which may differ from this first-publication example. Publication creates an immutable version. If backend publication is uncertain or fails, the new version does not become active until publication is confirmed; retry the same intended revision. Edit a draft with PATCH /organization/policies/{policy_id} and its current revision. Edits remain unpublished until the next publish. Fetch the latest policy before another mutation; stale revisions return 409.

4. Apply an optional policy

Include the published Limitless ID in any Chat, Responses, or Messages request:

{
  "model": "abliterated-model",
  "messages": [{ "role": "user", "content": "Help me choose a product." }],
  "max_tokens": 512,
  "policy_ids": ["pol_REPLACE_WITH_RETURNED_ID"]
}

The placeholder must be replaced with an ID from your own policy API. Foreign, missing, unpublished, or paused selected policies are rejected. Customer IDs are resolved within the organization and project; internal backend policy IDs are never customer credentials. Monitoring evaluates without enforcing a match. Enforcing rules can reject requests or responses. policy_violation and policy_evaluation_unavailable use policy_error with a request ID. Response policies can delay streamed text until evaluation finishes. A failed policy evaluation releases its reservation without a generation charge; a policy violation can still carry billable reported usage. Policy checks are not a guarantee that every undesired input or output will be detected.

5. Operate the policy

Pause or resume with POST /organization/policies/{policy_id}/pause or /resume, including the latest revision. Read version history through /versions and /versions/{version}. Inspect automatic rules for a project through /organization/projects/{project_id}/effective_policies. Delete with DELETE /organization/policies/{policy_id}?revision=LATEST_REVISION. This removes future application; requests already dispatched may still finish under the earlier snapshot.

Start here

Build

Administer

Operate

Manage policies in the console

1. Create a draft

2. Select scope

3. Publish a version

4. Apply an optional policy

5. Operate the policy

​Manage policies in the console

​1. Create a draft

​2. Select scope

​3. Publish a version

​4. Apply an optional policy

​5. Operate the policy

Manage policies in the console

1. Create a draft

2. Select scope

3. Publish a version

4. Apply an optional policy

5. Operate the policy