prisma-migrate

Migrate Prisma Access configurations between different SCM tenants (TSGs). Use when moving security policies, NAT rules, address objects, and other configura...

Security Scan

The skill's stated purpose (Prisma Access tenant-to-tenant migration) matches the instructions, but the declared required environment variables and metadata do not match the SKILL.md and reference docs — this mismatch is an incoherence that could break runs or lead users to supply incorrect credentials.

Purpose & Capability

The skill's name, description, and runtime instructions all describe migrating Prisma Access (SCM) configurations via the Palo Alto Networks Strata Cloud Manager API — the declared need for API credentials and curl/jq is consistent with that purpose.

Instruction Scope

The SKILL.md and reference file instruct the agent to perform OAuth token requests and many GET/POST calls against api.sase.paloaltonetworks.com and auth.apps.paloaltonetworks.com, and show example environment variables named SRC_SCM_*/DST_SCM_* and SCM_TSG_ID. However, the skill's declared requirements list only SCM_CLIENT_ID and SCM_CLIENT_SECRET (singular) and no TSG IDs. The runtime instructions therefore reference environment variables that the registry metadata does not declare — an inconsistency that can cause failures or misconfiguration. Apart from that mismatch, the instructions do not direct traffic to unexpected external endpoints or ask to read unrelated system files.

Install Mechanism

This is an instruction-only skill with no install spec or code files, so nothing is written to disk by an installer. It relies on standard CLI tools (curl, jq) which are reasonable for making API calls and processing JSON.

Credentials

Requesting SCM API credentials is appropriate for this migration task, but the declared required env vars (SCM_CLIENT_ID, SCM_CLIENT_SECRET) are insufficient and mismatched vs. the SKILL.md examples (SRC_SCM_CLIENT_ID, SRC_SCM_CLIENT_SECRET, DST_SCM_CLIENT_ID, DST_SCM_CLIENT_SECRET, SRC_SCM_TSG_ID, DST_SCM_TSG_ID). The primaryEnv is set to SCM_CLIENT_ID in metadata, which doesn't reflect that two separate tenant credentials and TSG IDs are needed. This ambiguity increases chance of credential mishandling and operational error. No unrelated credentials are requested.

Persistence & Privilege

The skill is not always-enabled and disable-model-invocation is true (so the model cannot autonomously invoke it). It does not request system config paths or attempt to persist beyond its own runtime instructions.

What to consider before installing

This skill appears to implement Prisma Access tenant-to-tenant migration via the official SCM APIs and uses curl/jq — that part is coherent. However, the registry metadata's required env vars (SCM_CLIENT_ID, SCM_CLIENT_SECRET) do not match the SKILL.md and reference docs, which show separate source and destination credentials and TSG IDs (e.g., SRC_SCM_CLIENT_ID, DST_SCM_CLIENT_ID, SRC_SCM_TSG_ID, DST_SCM_TSG_ID). Before installing or running: - Review the SKILL.md and reference/migration-workflow.md fully and ensure you export the exact environment variables the scripts expect (source and target client_id/client_secret and TSG IDs). The registry metadata may be incomplete or outdated. - Use least-privileged service accounts tailored for migration; some APIs (URL/Data/AI profiles) require elevated rights — avoid using broad admin credentials unless necessary. - Test on a non-production tenant first and verify the migration flow (export → transform → import → candidate push) with limited objects. - Keep credentials scoped and rotate them after use; do not reuse long-lived high-privilege credentials. - Because this is instruction-only (runs curl against Palo Alto endpoints), confirm that your environment has curl and jq and that network egress to auth.apps.paloaltonetworks.com and api.sase.paloaltonetworks.com is allowed. - If you need clarity, contact the skill author or inspect any runtime scripts you plan to run to ensure they reference the correct env var names and do not exfiltrate data to third-party endpoints. Given the metadata/instruction mismatch, proceed with caution and correct the environment variable usage before trusting the tool in production.

Prisma Access Tenant-to-Tenant Configuration Migration

Migrate configurations between Prisma Access tenants (TSGs) via the Strata Cloud Manager API.

Overview

This skill helps you export configurations from a source tenant and import them into a target tenant. It handles naming conflicts, reference resolution, and dependency ordering.

For detailed API call reference, see migration-workflow.md.

Migration Compatibility Matrix

Based on real-world migration testing, here is what can and cannot be migrated directly via SCM API:

Directly Migratable (API fully supported)

Resource	Notes
Tags	No issues
Address Objects	IP netmask, FQDN, IP range, IP wildcard all supported
Address Groups	Static and dynamic; referenced addresses must exist first
Service Objects	No issues
Service Groups	No issues
Application Filters	No issues
Application Groups	No issues
External Dynamic Lists (EDL)	No issues
HIP Objects	No issues
HIP Profiles	No issues
File Blocking Profiles	No issues
Profile Groups	Supported, but referenced sub-profiles must exist first
Security Rules (most)	Simple rules migrate directly
NAT Rules	No issues
Decryption Rules (most)	Simple rules migrate directly

Not Directly Migratable (require manual handling)

Resource	Issue	Workaround
URL Filtering Profiles	Service Account returns Access denied	Grant additional API permissions, or recreate manually in SCM console
Data Filtering Profiles	Service Account returns Access denied	Same as above
AI Security Profiles	Service Account returns Access denied	Same as above
Custom URL Categories	API returns 0 results or Access denied	Recreate manually in SCM console before migrating rules that reference them
Profile Groups with inaccessible refs	References URL Filtering / Data Filtering / AI Security profiles that can't be exported	Migrate with invalid references stripped; add them back manually after creating the sub-profiles in the target tenant
Rules referencing missing objects	Security/Decryption rules fail with INVALID_REFERENCE	Create the missing referenced objects first, then retry the rule
app-tagging rules	Nested object arrays cause Invalid Request Payload	Recreate manually in SCM console
Cross-folder name conflicts	Rules with same name in All or Prisma Access folder cause UNIQUEIN_ERROR	Skip — these are typically system-preset rules already present in the target

Key Lessons

1. Dependency order is critical: Tags → Addresses → Groups → Services → File Blocking Profiles → URL/Data/AI Profiles → Profile Groups → Rules
2. Service Account permissions are the biggest blocker: URL Filtering, Data Filtering, and AI Security profile APIs require elevated permissions that default Service Accounts may not have
3. Conflict detection must check ALL folders: Rules exist across Shared, All, Prisma Access, Mobile Users folders — checking only Shared misses conflicts
4. Profile Groups can be partially migrated: Strip invalid references, import the group, then manually add the missing references later
5. System-preset objects should be skipped: Both tenants share identical predefined objects (best-practice profiles, default EDLs, default HIP objects)
6. Fields to strip before import: id, created, last_modified, snippet, override_loc, override_type, override_id, rule_uuid, folder, policy_type, position (position goes in the query parameter instead)

Prerequisites

Set the following environment variables:

# Source tenant credentials
export SRC_SCM_CLIENT_ID="source-client-id"
export SRC_SCM_CLIENT_SECRET="source-client-secret"
export SRC_SCM_TSG_ID="source-tsg-id"

# Target tenant credentials
export DST_SCM_CLIENT_ID="target-client-id"
export DST_SCM_CLIENT_SECRET="target-client-secret"
export DST_SCM_TSG_ID="target-tsg-id"

Migration Workflow

Step 1: Export from Source Tenant

Authenticate and export all configuration objects from the source tenant via SCM API:

GET https://api.sase.paloaltonetworks.com/sse/config/v1/{resource}?folder={folder}&limit=200

Export objects in dependency order. Handle pagination with offset when total exceeds limit.

Step 2: Conflict Detection

Before importing, check the target tenant for conflicts across all folders (Shared, All, Prisma Access, Mobile Users, Remote Networks):

• Name conflicts: objects with the same name — typically skip (system presets)
• Reference conflicts: objects referencing things not in the target — need to create dependencies first or strip invalid references
• Cross-folder conflicts: rules in All folder that block creation in Shared — skip these

For each conflict, present the user with options:

• Skip: do not import (recommended for system presets)
• Overwrite: replace the target object with the source object
• Rename: import with a prefix/suffix (e.g., migrated- prefix)
• Strip references: import without invalid references, fix manually later

Step 3: Transform and Import

For each object:

1. Remove source-tenant-specific fields (id, created, last_modified, snippet, override_loc, override_type, override_id, rule_uuid)
2. Remove folder and policy_type from the body (folder goes in query param)
3. For rules: remove position from body (goes in query param as &position=pre or &position=post)
4. For Profile Groups with invalid references: strip the unavailable sub-profile references
5. POST to the target tenant API

POST https://api.sase.paloaltonetworks.com/sse/config/v1/{resource}?folder={folder}

Step 4: Validation

After import:

1. List all imported objects and verify counts match source
2. Check for broken references
3. Run a candidate config push to validate (without committing)

POST https://api.sase.paloaltonetworks.com/sse/config/v1/config-versions/candidate:push

Step 5: Commit (User-Confirmed)

Only commit after user explicitly confirms:

POST https://api.sase.paloaltonetworks.com/sse/config/v1/config-versions/running:push

Usage Examples

/prisma-access:prisma-migrate

Interactive mode: prompts for source and target tenant details.

/prisma-access:prisma-migrate 1234567890 0987654321

Migrate from TSG 1234567890 to TSG 0987654321.

Safety Guardrails

• Dry-run by default: always show what would be imported before making changes
• No auto-commit: never commit configuration without explicit user confirmation
• Rollback guidance: provide instructions to undo changes if needed
• Rate limiting: respect SCM API rate limits (avoid bulk API flooding)
• Skip system presets: automatically skip predefined objects that exist in both tenants