When you enable selective traffic steering for container workloads, you must choose "namespace" as the application boundary during cloud account onboarding. If you select "cluster name" instead, the generated SubnetInfo YAML file incorrectly populates the namespace field with the cluster name, which prevents deployment. If you select "tags," the generated `CR.yaml` file will be empty, also preventing deployment.

Workaround: Ensure you set the application boundary for container workloads to "namespace" scope during cloud account onboarding.

When you deploy "Per App SLR" Terraform, the management interface doesn’t have internet connectivity due to a missing Internet Gateway (IGW) connection in the route table for the management subnet.

When you download a deployment Terraform with traffic steering inspection enabled, the `pan-cni-svc-eps.yaml` file may incorrectly contain multiple endpoints, even if you selected only one zone in the deployment workflow. This can cause the Helm installation to fail.

Workaround: Manually modify the pan-cni-svc-eps.yaml file to remove the extra endpoint information, and ensure it reflects only the zones you selected during configuration.

When you deploy serverless workloads in Azure, the unprotected traffic from those functions is not visible in the Strata Cloud Manager dashboard, even when the functions are associated with a VNet that has flow logs enabled. This can lead you to mistakenly believe that there is no unprotected traffic from your serverless functions, even though you may see errors related to flow log processing on your Grafana dashboard.

Workaround: To secure and monitor this traffic, deploy the Prisma AIRS AI Runtime: Network intercept. The firewall successfully steers, processes, and protects the traffic, ensuring sessions are properly established and visible in your logs.

A deleted cloud asset continues to appear in the Strata Cloud Manager discovery UI for approximately 24 hours after deletion from the cloud environment.

Workaround: Download the image and manually deploy it on the firewall directly with the firewall web interface or PAN-OS CLI commands.

Prisma AIRS: Network intercept may not fully discover unprotected pod traffic in Kubernetes clusters running on AWS. This impacts the visibility of such traffic in the Strata Cloud Manager discovery command center despite enabling AWS VPC flow logs.

Workaround: To discover the pod’s traffic, add the AmazonEKSAdminViewPolicy to the K8s cluster for the role you created when applying the onboarding Terraform.

Prisma AIRS: Network intercept doesn't display unprotected traffic from Kubernetes pods in Azure environments within the Strata Cloud Manager discovery command center. This occurs because Azure VNET flow logs only provide IP addresses without pod-specific identifiers, making it impossible to distinguish between VM and Kubernetes cluster traffic.

Workaround: View the Application discovery page (internet-users section) to see the total count of all unprotected Azure applications.

Prisma AIRS: Network intercept may not immediately display unprotected model traffic on the Models page for AWS environments. This occurs because the system cannot properly match instance identifiers between flow logs and model invocation logs, particularly when instance profiles and IAM roles use different naming conventions. As a result, AI traffic from applications to Bedrock models may not appear in the Models page despite being actively used.

Verify your Strata Logging Service license status when creating a deployment profile in the Customer Support Portal. If the Strata Logging Service has expired, renew it before onboarding a cloud account to ensure successful onboarding Terraform generation.

Workaround: Remove the DLP profile from the security group in Strata Cloud Manager and push the configuration to Tag Collector.

After adding a Panorama deployment profile to the Hub, it may take up to an hour to push the AI security profiles to the AI core service.

Workaround: Configure AI profile with model group protections for Data Protection → Database Security without exiting the edit window for the security profile and sub-windows.

Workaround: When you create a Kubernetes cluster, enable the "Bring your own Azure virtual network" option in the Azure Portal for proper discovery. To enable this:

• In Azure Portal, navigate to Kubernetes services > [Your Cluster] > Settings > Networking.
• Under Network configuration, select Azure CNI as the Network plugin.
• Enable the Bring your own Azure virtual network toggle.

Traffic routing between fw-trust-vpc and app-vpc via VPC peering is currently blocked because the route export from fw-trust-vpc to app-vpc for 0.0.0.0/0 to ILB is hindered by an existing default gateway route in the app-vpc.

Workaround: Create a default route in the app-vpc which uses the Prisma AIRS ILB as the next hop. This ensures traffic routes correctly through the Prisma AIRS: Network intercept (AI firewall), enforcing security policies.

While deploying an Prisma AIRS: Network intercept in Strata Cloud Manager, selecting the application namespace does not retrieve the cluster pod and service CIDR.

Workaround: After generating the Terraform configuration, please whitelist these CIDR values in the Firewall Trust VPC firewall rule.

Detection logs for AI threats are missing in the AI security threat logs under Strata Cloud Manager (Incidents and Alerts → Log Viewer) when AI models are targeted by GenAI prompts.

This issue occurs when AI LLM applications are defined in the security policy, but the necessary dependent applications (such as SSL and web browsing) are not included. As a result, the AI network intercept provides inaccurate threat verdicts.

Workaround: Navigate to Manage → Configuration → NGFW and Prisma Access → Security Services → Security Policy and scope it to your AI network intercept. Edit the policy to include the dependent apps (web browsing and SSL apps). This will ensure the AI network intercept detects and logs AI security threats correctly in the Log Viewer.

The issue occurs when you upgrade the AI Runtime Security tag collector from `v11.2.2-h1` to `v11.2.3`, the tag-collector enters a rebooting loop and eventually goes to maintenance mode.

Workaround: Don’t upgrade to `v11.2.3` as the auto-commit feature is not triggered in `v11.2.3`.

Workaround: Use `n2-standard-4` or `Standard_DS3_v2` instance sizes for running `v11.2.2-h1` to avoid this issue.