zscaler/zscaler-mcp-server/create-access-policy-rule

ZPA: Create Access Policy Rule

Keywords

access policy, access rule, allow rule, deny rule, zpa policy, scim group policy, saml policy, platform restriction, country restriction, posture check, require approval, zero trust policy, conditional access

Overview

Create ZPA access policy rules that control who can access private applications. Access policies use the v2 condition format and support a rich set of condition types: identity-based (SAML/SCIM), device-based (platform, posture, Chrome Enterprise), network-based (trusted networks, country codes), and risk-based (ZIA risk factors).

Use this skill when: An administrator asks to create an access policy rule, grant or deny application access based on user identity, device posture, location, or any combination of conditions.

Condition Object Type Reference

Each condition block must contain a single object type. Multiple condition blocks are ANDed together. Within a condition block, multiple operands or entry_values are ORed.

Value-Based Object Types (use values)

Entry-Values Object Types (use entry_values with lhs/rhs)

Action Types

Workflow

Step 0: Identify the Rule Class (baseline alignment)

Reference: ZPA Baseline Recommendations v1.0 §Access Policy Construction (A–H). Before building conditions, identify which rule class this fits — that determines where the rule belongs in the policy order and which conditions are mandatory.

Per-OS posture gotcha

Defining a posture-block rule for only Windows leaves macOS, iOS, Android, and Linux implicitly allowed even when their device posture has failed. The doc is explicit about this on page 30: create one block rule per OS in use, each with its own POSTURE and PLATFORM criteria. This is the #1 posture-enforcement mistake.

When NOT to use this skill

• Building a baseline policy from scratch (multiple classes at once) — defer to a future bulk-build skill, or chain calls to this skill once per class.
• Auditing policy alignment — use the audit-baseline-compliance skill.

Step 1: Gather Requirements

Ask the administrator:

Required:

• Rule name
• Action: ALLOW, DENY, or REQUIRE_APPROVAL
• What conditions determine access (identity, platform, location, etc.)

Optional:

• Description
• Which application segments or segment groups to scope to
• App connector group IDs or server group IDs

Step 2: Look Up Identity Attributes

If the rule uses identity-based conditions (SAML, SCIM, SCIM_GROUP), look up the required IDs first.

For SCIM groups:

get_zpa_scim_group(search="<group_name>")

Note both the SCIM group ID (used as rhs) and the Identity Provider ID (used as lhs).

For SAML attributes:

get_zpa_saml_attribute(search="<attribute_name>")

Note the SAML attribute ID (used as lhs). The rhs is the value to match (e.g., an email address or group name string).

For SCIM attributes:

get_zpa_scim_attribute(search="<attribute_name>")

For segment groups (APP_GROUP):

zpa_list_segment_groups()

For posture profiles:

get_zpa_posture_profile(search="<profile_name>")

Note the posture_udid value (used as lhs).

For trusted networks:

get_zpa_trusted_network(search="<network_name>")

Note the network_id value (used as lhs).

Step 3: Build the Conditions Payload

Conditions use a list of dictionaries. Each dictionary represents one condition block with an operator and operands. Separate condition blocks for each object type.

Format:

[
  {
    "operator": "OR",
    "operands": [
      {
        "object_type": "<OBJECT_TYPE>",
        "values": ["<id1>", "<id2>"]
      }
    ]
  },
  {
    "operator": "OR",
    "operands": [
      {
        "object_type": "<OBJECT_TYPE>",
        "entry_values": [
          {"lhs": "<lhs_value>", "rhs": "<rhs_value>"}
        ]
      }
    ]
  }
]

Rules:

• Each condition block contains one object type only
• Multiple condition blocks are ANDed together (all must match)
• Within a block, multiple entry_values or multiple values are ORed (any can match)
• Value-based types (APP, APP_GROUP, CLIENT_TYPE, etc.) use values
• Entry-based types (SAML, SCIM_GROUP, PLATFORM, etc.) use entry_values

Step 4: Create the Rule

zpa_create_access_policy_rule(
  name="<rule_name>",
  action_type="ALLOW",
  description="<description>",
  conditions=<conditions_payload>,
  app_connector_group_ids=["<optional_connector_group_ids>"],
  app_server_group_ids=["<optional_server_group_ids>"]
)

Step 5: Verify

zpa_get_access_policy_rule(rule_id="<returned_rule_id>")

Ready-to-Use Examples

Example 1: Allow SCIM Groups to Access a Segment Group

Allow members of "Engineering" or "DevOps" SCIM groups to access an application segment group.

Step 1: Look up IDs

get_zpa_scim_group(search="Engineering")
get_zpa_scim_group(search="DevOps")
zpa_list_segment_groups()

Step 2: Create rule

zpa_create_access_policy_rule(
  name="Allow Engineering and DevOps",
  action_type="ALLOW",
  description="Grants Engineering and DevOps teams access to internal apps",
  conditions=[
    {
      "operator": "OR",
      "operands": [
        {
          "object_type": "APP_GROUP",
          "values": ["<segment_group_id>"]
        }
      ]
    },
    {
      "operator": "OR",
      "operands": [
        {
          "object_type": "SCIM_GROUP",
          "entry_values": [
            {"lhs": "<idp_id>", "rhs": "<engineering_scim_group_id>"},
            {"lhs": "<idp_id>", "rhs": "<devops_scim_group_id>"}
          ]
        }
      ]
    }
  ]
)

Logic: User must be in the segment group's apps AND be a member of Engineering OR DevOps.

Example 2: Allow SAML Users with Platform Restriction

Allow specific SAML-identified users, but only from macOS and Windows devices.

Step 1: Look up SAML attribute

get_zpa_saml_attribute(search="Email_Users")

Step 2: Create rule

zpa_create_access_policy_rule(
  name="Allow Specific Users on Mac/Windows",
  action_type="ALLOW",
  conditions=[
    {
      "operator": "OR",
      "operands": [
        {
          "object_type": "SAML",
          "entry_values": [
            {"lhs": "<saml_email_attribute_id>", "rhs": "alice@company.com"},
            {"lhs": "<saml_email_attribute_id>", "rhs": "bob@company.com"}
          ]
        }
      ]
    },
    {
      "operator": "OR",
      "operands": [
        {
          "object_type": "PLATFORM",
          "entry_values": [
            {"lhs": "mac", "rhs": "true"},
            {"lhs": "windows", "rhs": "true"}
          ]
        }
      ]
    }
  ]
)

Logic: User must match a SAML email AND be on macOS OR Windows.

Example 3: Country-Based Access Restriction

Allow access only from the United States and Canada.

zpa_create_access_policy_rule(
  name="US and Canada Only",
  action_type="ALLOW",
  description="Restrict access to US and Canadian locations",
  conditions=[
    {
      "operator": "OR",
      "operands": [
        {
          "object_type": "APP_GROUP",
          "values": ["<segment_group_id>"]
        }
      ]
    },
    {
      "operator": "OR",
      "operands": [
        {
          "object_type": "COUNTRY_CODE",
          "entry_values": [
            {"lhs": "US", "rhs": "true"},
            {"lhs": "CA", "rhs": "true"}
          ]
        }
      ]
    }
  ]
)

Example 4: Posture-Based Access with Risk Factor

Allow access only from devices that pass a posture check and have a ZIA risk score of LOW or below.

Step 1: Look up posture profile

get_zpa_posture_profile(search="CrowdStrike_ZTA")

Step 2: Create rule