Zms Assess Workload Protection

by zscaler809f68d6c921No licenseListed Oct 8, 2026Updated Oct 8, 2026

Assess Zscaler Microsegmentation (ZMS) workload protection coverage and identify protection gaps. Investigates resource protection status, resource group membership, unprotected workloads by cloud and region, and resource group coverage gaps. Use when an administrator asks: 'Which workloads are unprotected?', 'What is our microsegmentation coverage?', 'Find protection gaps', 'Which resource groups have no policies?', 'Show me unprotected resources', or 'What is our workload coverage percentage?'

Instructions onlySecurity

AI-generated overview

Assesses Zscaler Microsegmentation workload protection coverage and identifies unprotected workloads and coverage gaps.

What it does: Runs a six-step assessment of workload protection in Zscaler Microsegmentation: it pulls overall protection status, inventories resources, analyzes resource group coverage, and traces root causes of gaps such as missing group membership, missing policy rules, disconnected agents, and stale group criteria. It breaks coverage down by cloud provider, resource type, and app zone, then produces a protection assessment report with an executive summary, tables of unprotected workloads, and a prioritized remediation plan. All ZMS tools used are read-only queries.
When to use it: Use when an administrator asks which workloads are unprotected, what the microsegmentation coverage percentage is, which resource groups have no policies, or where protection gaps exist. It also fits preparing coverage reports for compliance, checking whether new deployments have adequate segmentation, and tracking protection percentage over time.
Requirements: Requires the ZSCALER_CUSTOMER_ID environment variable and access to ZMS MCP query tools (read-only). No scripts ship with the skill; remediation must be done through the Zscaler admin portal or ZMS API.

ZMS: Assess Workload Protection & Coverage Gaps

Keywords

workload protection, protection gaps, unprotected resources, protection status, resource groups, resource coverage, microsegmentation coverage, workload inventory, protected workloads, coverage percentage, security gaps, lateral movement risk

Overview

Perform a focused assessment of workload protection coverage in Zscaler Microsegmentation. This skill systematically identifies unprotected resources, analyzes resource group coverage, breaks down protection status by cloud provider and region, and produces an actionable remediation plan to close coverage gaps.

In a microsegmentation deployment, a workload (resource) is "protected" when:

An agent is deployed and connected on the workload
The workload belongs to at least one resource group
The resource group is referenced by at least one policy rule

A gap at any of these three levels leaves the workload exposed to lateral movement. This skill investigates all three levels to find exactly where coverage breaks down.

Use this skill when: An administrator needs to identify unprotected workloads for remediation, prepare protection coverage reports for compliance, assess whether new deployments have adequate segmentation, or track protection percentage over time.

Important:

All ZMS tools require ZSCALER_CUSTOMER_ID to be set as an environment variable.
All current MCP tools are read-only (Query operations).
Remediation (creating resource groups, adding policy rules) must be done through the Zscaler admin portal or the ZMS API directly.

Workflow

Follow this 6-step process for a complete workload protection assessment.

Step 1: Get the Protection Status Overview

Get overall resource protection status:

text

zms_get_resource_protection_status(page_num=1, page_size=100)```text
This returns the headline metric:
- **Total resources**: All workloads discovered by agents- **Protected count**: Workloads with active segmentation coverage- **Unprotected count**: Workloads without policy coverage- **Protection percentage**: The primary coverage KPI
**Target thresholds:**
- **> 95%**: Mature deployment — focus on closing remaining gaps- **90-95%**: Good coverage — systematic remediation plan needed- **80-90%**: Moderate coverage — significant gaps exist- **< 80%**: Low coverage — microsegmentation is partially deployed
---
### Step 2: Inventory All Workloads
**List all resources:**
```textzms_list_resources(page_num=1, page_size=50)```text
For each resource, capture:
- **Name/hostname**: Workload identifier- **Type**: VM, container, bare metal- **Cloud provider**: AWS, Azure, GCP, on-premises- **Region/availability zone**: Geographic location- **OS**: Operating system- **IP addresses**: Network addresses- **App zone**: Application zone membership- **Protection status**: Whether this specific workload has policy coverage
**Paginate through all resources for large environments:**
```textzms_list_resources(page_num=2, page_size=50)```text
**Include deleted resources for a complete audit trail:**
```textzms_list_resources(page_num=1, page_size=50, include_deleted=True)```text
This helps identify:
- Recently decommissioned workloads that may still appear in resource groups- Workloads removed from the fleet that had policy coverage- Ghost entries that need cleanup
---
### Step 3: Analyze Protection by Resource Group
**List all resource groups:**
```textzms_list_resource_groups(page_num=1, page_size=50)```text
**Get group-level protection status:**
```textzms_get_resource_group_protection_status(page_num=1, page_size=50)```text
**For each resource group, classify:**
- **Fully protected**: All members have policy coverage- **Partially protected**: Some members covered, some not- **Unprotected**: Group exists but no policy rules reference it- **Empty**: Group has 0 members (may be misconfigured or unused)
**Investigate specific groups with issues:**
```textzms_get_resource_group_members(    group_id="<group_id>",    page_num=1,    page_size=50)```text
For groups with protection gaps, list members to identify exactly which workloads are unprotected.
**Document group types:**
- **Managed groups** (tag-driven): Check if tag criteria are too narrow (excluding workloads) or too broad (including unintended workloads)- **Unmanaged groups** (CIDR/FQDN): Check if CIDR ranges are current and match actual infrastructure
---
### Step 4: Identify Root Causes of Gaps
**For each unprotected workload, determine the root cause:**
**Cause 1: Workload not in any resource group**
- The workload has an agent but isn't classified into any group- For managed groups: workload tags don't match any group's tag criteria- For unmanaged groups: workload IP is outside all defined CIDRs- **Fix**: Add appropriate tags or update CIDR ranges
**Cause 2: Resource group has no policy rules**
- The workload is in a resource group, but no policy rule references that group- **Fix**: Create policy rules (via admin portal) that include this resource group as source or destination
**Cause 3: Agent not deployed or disconnected**
- The workload exists in cloud infrastructure but has no agent- Or the agent was deployed but is disconnected
**Verify agent coverage:**
```textzms_get_agent_connection_status_statistics()```text
**Correlate with resource list:**
```textzms_list_agents(page=1, page_size=50)```text
Compare the agent list with the resource list. Resources without a corresponding connected agent represent deployment gaps.
**Cause 4: Stale resource group membership**
- Managed group tag criteria no longer match the workload's current tags- Unmanaged group CIDRs are outdated after infrastructure changes- **Fix**: Update tag criteria or CIDR definitions
---
### Step 5: Break Down Coverage by Dimensions
**Analyze coverage across dimensions using the resource list from Step 2:**
**By cloud provider:**
```textCoverage by Cloud Provider============================AWS:          145/160 protected (90.6%)Azure:         87/95  protected (91.6%)GCP:           35/40  protected (87.5%)On-Premises:   20/25  protected (80.0%)```text
**By resource type:**
```textCoverage by Resource Type===========================VMs:           172/180 protected (95.6%)Containers:     85/95  protected (89.5%)Bare Metal:     30/37  protected (81.1%)```text
**By app zone:**
```textCoverage by App Zone======================Web Tier:       48/48  protected (100%)App Tier:       62/65  protected (95.4%)DB Tier:        30/30  protected (100%)Shared Services: 25/25 protected (100%)Unzoned:        22/44  protected (50.0%)  ← CRITICAL```text
**"Unzoned" workloads** — resources not assigned to any app zone — are often the largest protection gap. They tend to be newly deployed workloads or infrastructure that was overlooked during initial segmentation rollout.
---
### Step 6: Build Remediation Plan
**Get resource event metadata for additional context:**
```textzms_get_metadata()```text
---
### Present Protection Assessment Report
```textWorkload Protection Assessment Report========================================Date: <current_date>Auditor: AI Assistant
## Executive Summary
- **Total Workloads:** 312- **Protected:** 287 (92.0%)- **Unprotected:** 25 (8.0%)- **Target Coverage:** > 95%- **Gap to Target:** 3.0% (10 additional workloads)- **Protection Status:** MODERATE — remediation required
---
## Protection Overview
| Metric | Count | Percentage | Target | Status ||--------|-------|-----------|--------|--------|| Protected | 287 | 92.0% | > 95% | BELOW || Unprotected | 25 | 8.0% | < 5% | ABOVE || Total | 312 | 100% | — | — |
---
## Coverage by Cloud Provider
| Cloud | Total | Protected | Unprotected | Coverage | Status ||-------|-------|-----------|-------------|----------|--------|| AWS | 160 | 145 | 15 | 90.6% | NEEDS WORK || Azure | 95 | 87 | 8 | 91.6% | NEEDS WORK || GCP | 40 | 35 | 5 | 87.5% | NEEDS WORK || On-Prem | 25 | 20 | 5 | 80.0% | CRITICAL |
---
## Coverage by Resource Type
| Type | Total | Protected | Unprotected | Coverage | Status ||------|-------|-----------|-------------|----------|--------|| VM | 180 | 172 | 8 | 95.6% | GOOD || Container | 95 | 85 | 10 | 89.5% | NEEDS WORK || Bare Metal | 37 | 30 | 7 | 81.1% | CRITICAL |
---
## Resource Groups with Gaps
| Group Name | Type | Members | Protected | Gap | Root Cause ||------------|------|---------|-----------|-----|------------|| New API Servers | Managed | 8 | 0 | 8 | No policy rules || Legacy Infra | Unmanaged | 5 | 2 | 3 | Stale CIDRs || (No group) | — | 14 | 0 | 14 | Not classified |
---
## Unprotected Workloads Detail
| Hostname | Cloud | Type | OS | IP | Gap Reason ||----------|-------|------|----|----|------------|| api-new-01 | AWS | VM | Ubuntu | 10.0.5.10 | No group || api-new-02 | AWS | VM | Ubuntu | 10.0.5.11 | No group || batch-worker-01 | GCP | VM | Debian | 10.2.1.5 | No policy || ... | ... | ... | ... | ... | ... |
---
## Remediation Plan
### Priority 1: Immediate (14 workloads — no resource group)- Create managed resource groups with tag criteria matching these workloads- OR add workload IPs to existing unmanaged resource groups- Expected coverage improvement: +4.5%
### Priority 2: High (8 workloads — group exists, no policy)- Create policy rules for "New API Servers" resource group- Define allowed communication paths (ports, protocols, directions)- Expected coverage improvement: +2.6%
### Priority 3: Medium (3 workloads — stale group membership)- Update CIDR ranges in "Legacy Infra" unmanaged resource group- Verify IP addresses match current infrastructure- Expected coverage improvement: +1.0%
### Projected Result After Remediation- Protected: 312/312 (100%)- All workloads covered by segmentation policies
---
## Trend Tracking
Recommend running this assessment monthly and tracking:- Protection percentage over time- New workload onboarding time-to-protection- Resource group membership changes- Policy rule creation rate vs workload growth rate```text
---
## Edge Cases
### 100% Protection Coverage
```textAll workloads are protected (100% coverage).
This is excellent! Verify this remains true by:1. Ensuring new workloads are auto-classified via managed resource   groups (tag-based membership)2. Monitoring agent deployment on new infrastructure3. Reviewing resource group membership after infrastructure changes4. Checking that decommissioned workloads are cleaned up```text
### No Resources Found
```textNo resources (workloads) found in the ZMS deployment.
Possible causes:- No agents are deployed or connected- Agents are deployed but haven't reported resource data yet- ZSCALER_CUSTOMER_ID may be incorrect
Action: Verify agent deployment usingzms_get_agent_connection_status_statistics() and checkZSCALER_CUSTOMER_ID configuration.```text
### All Unprotected Resources Are in One Cloud
```textAll 25 unprotected workloads are in AWS.
This suggests a deployment gap specific to AWS:- AWS tag integration may not be configured- New AWS accounts may not have agent deployment automation- AWS-specific resource groups may be missing
Action: Prioritize AWS tag integration and resource group creation.```text
---
## Quick Reference
**Primary workflow:** Protection Status → Inventory → Group Analysis → Root Causes → Dimensional Breakdown → Remediation
**Protection status tools:**
- `zms_get_resource_protection_status()` — overall protection metrics- `zms_get_resource_group_protection_status()` — per-group protection
**Resource tools:**
- `zms_list_resources(page_num, page_size)` — workload inventory- `zms_list_resources(include_deleted=True)` — including decommissioned- `zms_get_metadata()` — resource event metadata
**Resource group tools:**
- `zms_list_resource_groups()` — all groups with types- `zms_get_resource_group_members(group_id)` — members of a specific group
**Agent tools (for correlation):**
- `zms_get_agent_connection_status_statistics()` — agent deployment health- `zms_list_agents()` — individual agent status
**Not yet available via MCP tools:**
- Resource group create/update/delete- Policy rule create/update/delete- These must be performed through the Zscaler admin portal or the ZMS API

zms_get_resource_protection_status(page_num=1, page_size=100)```text
This returns the headline metric:
- **Total resources**: All workloads discovered by agents- **Protected count**: Workloads with active segmentation coverage- **Unprotected count**: Workloads without policy coverage- **Protection percentage**: The primary coverage KPI
**Target thresholds:**
- **> 95%**: Mature deployment — focus on closing remaining gaps- **90-95%**: Good coverage — systematic remediation plan needed- **80-90%**: Moderate coverage — significant gaps exist- **< 80%**: Low coverage — microsegmentation is partially deployed
---
### Step 2: Inventory All Workloads
**List all resources:**
```textzms_list_resources(page_num=1, page_size=50)```text
For each resource, capture:
- **Name/hostname**: Workload identifier- **Type**: VM, container, bare metal- **Cloud provider**: AWS, Azure, GCP, on-premises- **Region/availability zone**: Geographic location- **OS**: Operating system- **IP addresses**: Network addresses- **App zone**: Application zone membership- **Protection status**: Whether this specific workload has policy coverage
**Paginate through all resources for large environments:**
```textzms_list_resources(page_num=2, page_size=50)```text
**Include deleted resources for a complete audit trail:**
```textzms_list_resources(page_num=1, page_size=50, include_deleted=True)```text
This helps identify:
- Recently decommissioned workloads that may still appear in resource groups- Workloads removed from the fleet that had policy coverage- Ghost entries that need cleanup
---
### Step 3: Analyze Protection by Resource Group
**List all resource groups:**
```textzms_list_resource_groups(page_num=1, page_size=50)```text
**Get group-level protection status:**
```textzms_get_resource_group_protection_status(page_num=1, page_size=50)```text
**For each resource group, classify:**
- **Fully protected**: All members have policy coverage- **Partially protected**: Some members covered, some not- **Unprotected**: Group exists but no policy rules reference it- **Empty**: Group has 0 members (may be misconfigured or unused)
**Investigate specific groups with issues:**
```textzms_get_resource_group_members(    group_id="<group_id>",    page_num=1,    page_size=50)```text
For groups with protection gaps, list members to identify exactly which workloads are unprotected.
**Document group types:**
- **Managed groups** (tag-driven): Check if tag criteria are too narrow (excluding workloads) or too broad (including unintended workloads)- **Unmanaged groups** (CIDR/FQDN): Check if CIDR ranges are current and match actual infrastructure
---
### Step 4: Identify Root Causes of Gaps
**For each unprotected workload, determine the root cause:**
**Cause 1: Workload not in any resource group**
- The workload has an agent but isn't classified into any group- For managed groups: workload tags don't match any group's tag criteria- For unmanaged groups: workload IP is outside all defined CIDRs- **Fix**: Add appropriate tags or update CIDR ranges
**Cause 2: Resource group has no policy rules**
- The workload is in a resource group, but no policy rule references that group- **Fix**: Create policy rules (via admin portal) that include this resource group as source or destination
**Cause 3: Agent not deployed or disconnected**
- The workload exists in cloud infrastructure but has no agent- Or the agent was deployed but is disconnected
**Verify agent coverage:**
```textzms_get_agent_connection_status_statistics()```text
**Correlate with resource list:**
```textzms_list_agents(page=1, page_size=50)```text
Compare the agent list with the resource list. Resources without a corresponding connected agent represent deployment gaps.
**Cause 4: Stale resource group membership**
- Managed group tag criteria no longer match the workload's current tags- Unmanaged group CIDRs are outdated after infrastructure changes- **Fix**: Update tag criteria or CIDR definitions
---
### Step 5: Break Down Coverage by Dimensions
**Analyze coverage across dimensions using the resource list from Step 2:**
**By cloud provider:**
```textCoverage by Cloud Provider============================AWS:          145/160 protected (90.6%)Azure:         87/95  protected (91.6%)GCP:           35/40  protected (87.5%)On-Premises:   20/25  protected (80.0%)```text
**By resource type:**
```textCoverage by Resource Type===========================VMs:           172/180 protected (95.6%)Containers:     85/95  protected (89.5%)Bare Metal:     30/37  protected (81.1%)```text
**By app zone:**
```textCoverage by App Zone======================Web Tier:       48/48  protected (100%)App Tier:       62/65  protected (95.4%)DB Tier:        30/30  protected (100%)Shared Services: 25/25 protected (100%)Unzoned:        22/44  protected (50.0%)  ← CRITICAL```text
**"Unzoned" workloads** — resources not assigned to any app zone — are often the largest protection gap. They tend to be newly deployed workloads or infrastructure that was overlooked during initial segmentation rollout.
---
### Step 6: Build Remediation Plan
**Get resource event metadata for additional context:**
```textzms_get_metadata()```text
---
### Present Protection Assessment Report
```textWorkload Protection Assessment Report========================================Date: <current_date>Auditor: AI Assistant
## Executive Summary
- **Total Workloads:** 312- **Protected:** 287 (92.0%)- **Unprotected:** 25 (8.0%)- **Target Coverage:** > 95%- **Gap to Target:** 3.0% (10 additional workloads)- **Protection Status:** MODERATE — remediation required
---
## Protection Overview
| Metric | Count | Percentage | Target | Status ||--------|-------|-----------|--------|--------|| Protected | 287 | 92.0% | > 95% | BELOW || Unprotected | 25 | 8.0% | < 5% | ABOVE || Total | 312 | 100% | — | — |
---
## Coverage by Cloud Provider
| Cloud | Total | Protected | Unprotected | Coverage | Status ||-------|-------|-----------|-------------|----------|--------|| AWS | 160 | 145 | 15 | 90.6% | NEEDS WORK || Azure | 95 | 87 | 8 | 91.6% | NEEDS WORK || GCP | 40 | 35 | 5 | 87.5% | NEEDS WORK || On-Prem | 25 | 20 | 5 | 80.0% | CRITICAL |
---
## Coverage by Resource Type
| Type | Total | Protected | Unprotected | Coverage | Status ||------|-------|-----------|-------------|----------|--------|| VM | 180 | 172 | 8 | 95.6% | GOOD || Container | 95 | 85 | 10 | 89.5% | NEEDS WORK || Bare Metal | 37 | 30 | 7 | 81.1% | CRITICAL |
---
## Resource Groups with Gaps
| Group Name | Type | Members | Protected | Gap | Root Cause ||------------|------|---------|-----------|-----|------------|| New API Servers | Managed | 8 | 0 | 8 | No policy rules || Legacy Infra | Unmanaged | 5 | 2 | 3 | Stale CIDRs || (No group) | — | 14 | 0 | 14 | Not classified |
---
## Unprotected Workloads Detail
| Hostname | Cloud | Type | OS | IP | Gap Reason ||----------|-------|------|----|----|------------|| api-new-01 | AWS | VM | Ubuntu | 10.0.5.10 | No group || api-new-02 | AWS | VM | Ubuntu | 10.0.5.11 | No group || batch-worker-01 | GCP | VM | Debian | 10.2.1.5 | No policy || ... | ... | ... | ... | ... | ... |
---
## Remediation Plan
### Priority 1: Immediate (14 workloads — no resource group)- Create managed resource groups with tag criteria matching these workloads- OR add workload IPs to existing unmanaged resource groups- Expected coverage improvement: +4.5%
### Priority 2: High (8 workloads — group exists, no policy)- Create policy rules for "New API Servers" resource group- Define allowed communication paths (ports, protocols, directions)- Expected coverage improvement: +2.6%
### Priority 3: Medium (3 workloads — stale group membership)- Update CIDR ranges in "Legacy Infra" unmanaged resource group- Verify IP addresses match current infrastructure- Expected coverage improvement: +1.0%
### Projected Result After Remediation- Protected: 312/312 (100%)- All workloads covered by segmentation policies
---
## Trend Tracking
Recommend running this assessment monthly and tracking:- Protection percentage over time- New workload onboarding time-to-protection- Resource group membership changes- Policy rule creation rate vs workload growth rate```text
---
## Edge Cases
### 100% Protection Coverage
```textAll workloads are protected (100% coverage).
This is excellent! Verify this remains true by:1. Ensuring new workloads are auto-classified via managed resource   groups (tag-based membership)2. Monitoring agent deployment on new infrastructure3. Reviewing resource group membership after infrastructure changes4. Checking that decommissioned workloads are cleaned up```text
### No Resources Found
```textNo resources (workloads) found in the ZMS deployment.
Possible causes:- No agents are deployed or connected- Agents are deployed but haven't reported resource data yet- ZSCALER_CUSTOMER_ID may be incorrect
Action: Verify agent deployment usingzms_get_agent_connection_status_statistics() and checkZSCALER_CUSTOMER_ID configuration.```text
### All Unprotected Resources Are in One Cloud
```textAll 25 unprotected workloads are in AWS.
This suggests a deployment gap specific to AWS:- AWS tag integration may not be configured- New AWS accounts may not have agent deployment automation- AWS-specific resource groups may be missing
Action: Prioritize AWS tag integration and resource group creation.```text
---
## Quick Reference
**Primary workflow:** Protection Status → Inventory → Group Analysis → Root Causes → Dimensional Breakdown → Remediation
**Protection status tools:**
- `zms_get_resource_protection_status()` — overall protection metrics- `zms_get_resource_group_protection_status()` — per-group protection
**Resource tools:**
- `zms_list_resources(page_num, page_size)` — workload inventory- `zms_list_resources(include_deleted=True)` — including decommissioned- `zms_get_metadata()` — resource event metadata
**Resource group tools:**
- `zms_list_resource_groups()` — all groups with types- `zms_get_resource_group_members(group_id)` — members of a specific group
**Agent tools (for correlation):**
- `zms_get_agent_connection_status_statistics()` — agent deployment health- `zms_list_agents()` — individual agent status
**Not yet available via MCP tools:**
- Resource group create/update/delete- Policy rule create/update/delete- These must be performed through the Zscaler admin portal or the ZMS API

Source and attribution

Source:zscaler/zscaler-mcp-serverinskills/zms/assess-workload-protectionat commit809f68d

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal

Zms Assess Workload Protection

ZMS: Assess Workload Protection & Coverage Gaps

Keywords

Overview

Workflow

Step 1: Get the Protection Status Overview

Source and attribution

More from zscaler/zscaler-mcp-server

Zpa Troubleshoot App Connector

Zpa Create Timeout Policy Rule

Zpa Create Session Duration Rule

Zpa Create Server Group

Zpa Create Forwarding Policy Rule

Zpa Create Conditional Access Rule

More in Security

Dpop Adoption

Secops Triage

Secops Investigate

Secops Hunt

Secops Cases

Iam Helper For Privileged Access Management