zpa-create-conditional-access-rule

What this skill does

# ZPA: Create Conditional Access Rule (Multi-Check)

## Keywords

conditional access, multi-check access rule, layered access rule, identity + posture + platform + risk, attach posture profile to rule, attach risk score to rule, secure remote access SSH, internal app conditional access

## How to talk to the admin (read this before you respond)

The admin is asking a **business question** — *"can you build this access rule?"*. Tool plumbing is internal optimization the admin does not care about.

- **Plain language only.** Translate tool output into the answer the admin wanted. Don't paste back JMESPath expressions, `search` keys, projections, validation errors, Pydantic messages, or SDK tuple shapes.
- **Empty is authoritative — do not fan out retries.** A `zpa_list_*` call with `search="<exact name>"` is a server-side substring match on the resource's `name` field. **An empty result means the resource does not exist by that name. Stop.** Do NOT then re-call the same tool with split keywords, broader JMESPath projections, larger `page_size`, or no filter "to double-check". Each of those costs a round trip and adds zero information. The single allowed follow-up is asking the admin to clarify the name (see Hard Stops below).
  - ❌ Five calls: `search="DataCenter Switches SSH"` → empty → `query="[?contains(name,'DataCenter') || contains(name,'SSH')]"` → `query="[*].{id,name}", page_size=200` → unfiltered list → "let me drop the projection in case it's too aggressive".
  - ✅ One call: `search="DataCenter Switches SSH"` → empty → *"I can't find an application segment named `DataCenter Switches SSH`. Want me to use a different name?"*
- **Don't narrate strategy pivots.** If you do retry (only when allowed), do it quietly. Report only the final answer.
  - ❌ *"The `search` filter came back empty. The tool's `search` may not be a substring match. Let me list without the filter and apply JMESPath instead so I'm not relying on server-side fuzzy matching."*
  - ✅ *"I didn't find an application segment named `Example100`. Want me to use a different name, or list the segments that do exist?"*
- **Don't claim a tool doesn't exist without checking.** If a `zpa_get_*` / `zpa_create_*` is visible, the matching `zpa_list_*` almost certainly exists too. Examples that have been wrongly mis-claimed missing: `zpa_list_app_connector_groups`, `zpa_list_segment_groups`, `zpa_list_application_segments`.
- **Don't enumerate gaps the admin didn't ask about.** Mention a limitation only when it's about to block what the admin actually requested.

## Overview

This is the opinionated skill for the **conditional-access** scenario:
**identity + posture (often multiple) + platform + risk + country, all
AND-ed together**, gating access to a single internal application or
app segment.

It is **narrower and more opinionated** than the general-purpose
`zpa-create-access-policy-rule` skill. Use this skill when the request
explicitly combines several of: SCIM group / SAML attribute, device
posture profile(s), platform restriction, country restriction, and
risk-score level.

For arbitrary or simpler ZPA access rules, use `zpa-create-access-policy-rule`.

---

## What this skill supports

The agent does **not** introspect or verify what any of these operands
actually check on the device. ZPA Access Policy attaches operand
references (UDIDs, attribute IDs, OS names, country codes, score
levels) and trusts the truth value the ZCC client reports back when
the rule is evaluated. Re-authentication is **not** an Access Policy
concern — it is a separate ZPA Timeout Policy feature.

| Requirement | Operand | What the agent does |
|---|---|---|
| User in a specific SCIM group | `SCIM_GROUP` | Resolves the group name via `get_zpa_scim_group` (returns `idp_id` + group id) and attaches both. |
| User matches a SAML attribute | `SAML` | Resolves the attribute ID via `get_zpa_saml_attribute` and attaches with the value to match. |
| Associate a named device posture profile (e.g. "Enterprise PKI Certificate", "CrowdStrike EDR Active") | `POSTURE` (one block per profile when AND-ing — see note below) | Resolves the profile UDID by name via `get_zpa_posture_profile` and attaches `lhs=<udid>`, `rhs="true"`. The agent does **not** describe or validate what the profile checks — that lives entirely inside ZCC and is opaque to ZPA. |
| Operating system reported by the ZCC client | `PLATFORM` | Single operand: `lhs` ∈ {`windows`, `mac`, `linux`, `ios`, `android`}, `rhs="true"`. ZPA does not inspect anything else about the OS — no version, no patch level. |
| Country restriction | `COUNTRY_CODE` | ISO 3166 Alpha-2 codes; one entry per country. ZPA derives country from source IP. |
| Associate one or more risk-score levels with the rule | `RISK_FACTOR_TYPE` | `lhs="ZIA"`, `rhs` ∈ {`UNKNOWN`, `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`}. The score itself is computed elsewhere by Zscaler; the rule simply lists which levels are accepted. |
| Application = a specific private app segment | `APP` or `APP_GROUP` | Resolved via `zpa_list_application_segments` / `zpa_list_segment_groups` *by name*. |

### AND vs OR — get this right or the rule will be wrong

ZPA condition semantics:

- **Multiple condition blocks at the top level → ANDed.**
- **Multiple `entry_values` (or `values`) inside one block → ORed.**

This matters most for **POSTURE**. To require *"posture profile A
passes **AND** posture profile B passes"*, the agent **must create two
separate POSTURE condition blocks** — one per profile — not two
entries inside a single block. A single block with both entries means
"**either** A **or** B", which is almost never what the admin wants.

For COUNTRY_CODE (allow US **or** CA) or PLATFORM (Windows **or** Mac),
multiple entries in one block is correct, because OR is the desired
semantics there.

---

## Workflow

### Step 1: Confirm the admin's inputs

- **Application** — the name of the existing app segment (or segment
  group) the rule protects.
- **Identity scope** — SCIM group(s) or SAML attribute(s).
- **Posture profile names** required — list every profile that must
  pass. Each becomes its own `POSTURE` condition block.
- **Platform restriction** — which operating systems are allowed.
- **Country restriction** — ISO 3166 Alpha-2 codes (optional).
- **Risk-score levels** allowed — typical: `UNKNOWN` and `LOW`.
- **Action** — almost always `ALLOW` for this pattern.

---

### Step 2: Resolve IDs (read-before-write)

**One call per resource, with a `search` parameter set to the admin's
exact name. Empty result = resource does not exist; jump to the Hard
Stops below. Do not retry with broader filters or no filter.**

Run these in parallel where possible:

```text
get_zpa_scim_group(search="<group_name>")
get_zpa_posture_profile(search="<posture_profile_name>")  # repeat per profile
zpa_list_application_segments(search="<app_segment_name>")  # or zpa_list_segment_groups(search="<segment_group_name>")
```

If the admin gave a SAML email/attribute instead of a SCIM group, also
run `get_zpa_saml_attribute(search=<name>)`.

**Hard stop conditions** — if any of these fire, do NOT proceed to
write. Stop, ask the admin in **plain language**, do not narrate which
filter / search / projection you tried:

- The named application segment was not found. **Do not improvise a
  segment inline from this skill.** App segments depend on a chain
  (App Connector Group → Server Group → Segment Group → App Segment),
  and that chain is owned by the `zpa-application_segment-onboard` skill. Two
  valid paths:
  1. *"I can't find an application segment named `<name>`. Want me to
     use a different existing segment?"* — and proceed when the admin
     names one that does exist.
  2. *"I can't find an application segment named `<name>`. To create
     it, I'll hand off to the `zpa-application_segment-onboard` skill first
     (it walks the connector-group → server-group → segment-group →
     app-segment chain), then come back here to attach the