Sign-in rules
Sign-in rules decide whether and how a user can sign in to the Prisma Browser. They are the first policy a session is evaluated against. Rules are evaluated top to bottom within their sections; the first matching rule wins. See Policy overview for concepts shared across all policy types (scope, sections, positions, publishing).
The Policy APIs are in Beta and are enabled by request. Contact your account team to join the Beta program.
Base path: /seb-api/v1/policy/sign-in.
Mandatory fields
| Field | Required | Notes |
|---|---|---|
name | Yes | 1-300 characters |
mode | Yes | active or disabled (case-insensitive) |
action | Yes | allow, block, or prompt |
scope | No (recommended) | Who the rule applies to. Omitting it applies the rule to everyone. |
description | No | Up to 300 characters |
positioning | No | Where to place the new rule (section + position) |
A sign-in rule's only behavior is its action: let the user in (allow), keep them out (block), or make them confirm before continuing (prompt). There are no controls on sign-in rules.
Structure
{
"name": "Block sign-in from unmanaged devices",
"mode": "active",
"action": "block",
"scope": {
"deviceGroups": { "deviceGroups": ["0DGEXAMPLEUNMANAGEDXXXXXXXX"] }
}
}
Create a sign-in rule
POST /seb-api/v1/policy/sign-in/rules
curl -sS -X POST "$PB_API_BASE/policy/sign-in/rules" \
-H "Authorization: Bearer $PB_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name": "Allow sign-in for employees",
"mode": "active",
"action": "allow",
"scope": { "users": { "userGroups": ["0UGEXAMPLEEMPLOYEESXXXXXXXX"] } }
}'
Response
The resolved rule: the fields you sent, every server-side default filled in, and the new id.
The rule is created in the draft. Publish to enforce it (see Draft and publish).
Sections
Sign-in sections are created with POST /seb-api/v1/policy/sign-in/sections (only name is required) and ordered with the positions endpoints.