>
    Strata Copilot
    Changes to Default Behavior in Prisma Agent
    Focus
    Download PDF
    Focus
    1. Home
    2. Prisma Agent
    3. Prisma Agent Release Notes
    4. Prisma Agent Release Information
    5. Changes to Default Behavior in Prisma Agent
    Download PDF
    Prisma Agent

    Changes to Default Behavior in Prisma Agent

    Table of Contents

    Changes to Default Behavior in Prisma Agent

    Review the changes to default behavior in Prisma Agent.
    Where Can I Use This?What Do I Need?
    • Prisma Access (Managed by Panorama or Strata Cloud Manager)
    • NGFW (Managed by Panorama)
    • Check the prerequisites for the deployment you're using
    • Contact your Palo Alto Networks account representative to activate the Prisma Agent feature
    Changes to default behavior in the Prisma Agent are provided.

    Changes to Default Behavior in Prisma Agent 26.3

    Review the changes to default behavior in Prisma Agent 26.3.

    Separate Installer Packages for Endpoint DLP

    Prisma Agent 26.3 introduces separate installer packages for macOS and Windows deployments, one that includes Endpoint DLP and one that does not. In 26.2.1, a single installer included Endpoint DLP for all deployments; Endpoint DLP remained inactive unless you activated a separate license.
    Starting in 26.3, you can choose from the following packages from the Prisma Agent download dialog:
    • Prisma Agent with Endpoint DLP packages — Listed in the Endpoint DLP Packages section of the agent download dialog. Each package bundles Prisma Agent and Endpoint DLP together, so you only need to download one package. These packages require a separate Endpoint DLP license and can only be deployed via MDM. Download filenames: PrismaAccessAgent_x64_<version>.msi (Windows) or PrismaAccessAgentInstaller_<version>.pkg (macOS).
    • Standard Prisma Agent packages — Available in the standard packages section of the download dialog. These packages do not include Endpoint DLP. Download filenames: PrismaAccessAgent_NoDLP_x64_<version>.msi (Windows) or PrismaAccessAgentInstaller_NoDLP_<version>.pkg (macOS).
    Linux packages are not affected by this change. Linux does not support Endpoint DLP.
    To downgrade to a previous version, use the Endpoint Management page—there are no restrictions on downgrading.

    Changes to Default Behavior in Prisma Agent 26.2.2

    Review the changes to default behavior in Prisma Agent 26.2.2.

    Wildcard Support Added for Source Application Paths on Linux

    Prisma Agent 26.2.2 adds wildcard character support for source application paths on Linux endpoints, bringing Linux into parity with macOS and Windows.
    In 26.2.1, Linux endpoints required the complete real path of the application in source application rules and did not support wildcard characters. Starting in 26.2.2, you can use a single asterisk (*) as a wildcard to replace exactly one directory component in the path. This allows a single forwarding rule to match applications that install to version-specific or distribution-specific paths. The same wildcard syntax rules that apply to macOS and Windows now apply to Linux: each wildcard must be a single asterisk that occupies an entire directory component, and the path must begin with a valid root directory. Double asterisks (**) are not a valid wildcard pattern — if a path uses an unsupported pattern, the agent rejects the rule and traffic falls through to the Default profile.
    Wildcard support for source application paths is not available on Arch Linux ARM64. On Arch Linux ARM64, Prisma Agent cannot identify which application generated a given traffic flow, so source application rules — including those that use wildcards — do not apply. Use destination-based rules on Arch Linux ARM64 endpoints. Wildcard support for source application paths works as expected on Arch Linux x86_64 endpoints.
    If you previously configured destination-based workaround rules for Linux endpoints with variable application paths, you can now replace those rules with source application rules that use wildcards.

    Changes to Default Behavior in Prisma Agent 26.2.1

    Review the changes to default behavior in Prisma Agent 26.2.1.

    Changes in Default Behavior for Source Application-Based Traffic Steering on Linux

    Prisma Agent 26.2.1 for Linux now resolves the full real path of the source application to identify traffic origin, replacing the previous behavior where only the base name (for example, curl) was used.
    If you configured forwarding profile rules using source application criteria on Linux endpoints, those rules now require the complete real path of the application to match (for example, /opt/chrome/chrome). If the path you configured no longer matches the resolved real path, the rule is skipped and the agent evaluates the next rule in the forwarding profile, eventually falling back to the Default rule.
    Source application rules with stable, predictable paths continue to work. However, if an application installs to a path that contains dynamically generated components (such as version-specific integers) or varies across Linux distributions, you can't reliably configure a path that matches consistently. Unlike macOS and Windows agents, Linux does not support wildcard characters in source application paths.
    For applications with variable or unpredictable install paths, replace source application-based forwarding rules with destination-based rules using FQDNs or IP address ranges to ensure consistent traffic steering on Linux endpoints.

    Changes in Default Behavior for Endpoint DLP

    Prisma Agent 26.2.1 introduces the following changes in behavior for Endpoint DLP:
    • App visibility: Prisma Endpoint DLP is installed as a separate application visible on the endpoint. In previous versions, only the Endpoint DLP service was installed in the background along with the installation of Prisma Agent, with no corresponding app entry visible to users or administrators on the endpoint.
    • Service startup: The Endpoint DLP service remains inactive until the Endpoint DLP license is activated. In previous versions, Endpoint DLP was installed along with the Prisma Agent but the service remained inactive until DLP policies were pushed to the endpoint.

    Changes to Default Behavior in Prisma Agent 25.7

    Review the changes to default behavior in Prism Access Agent 25.7.

    Changes in Default Behavior for HIP Reports

    Prisma Agent automatically attempts to resubmit Host Information Profile (HIP) reports when initial transmission to the gateway fails due to network timeouts or connectivity issues. The agent performs up to three retry attempts and logs all retry attempts with timestamps for troubleshooting purposes. You can monitor retry status through the pacli hip status command, which provides visibility into retry attempts and their outcomes.

    Changes in Default Behavior for Unified Configuration Profiles for macOS Agents

    Palo Alto Networks provides unified configuration profiles to streamline the deployment of Prisma Agents for macOS, eliminating the need for end-user interaction and manual administrator configuration.
    If you use unified configuration profiles for agent deployment, starting with Prisma Agent 25.7, you must use the latest unified configuration profiles (V3). The V3 profiles are compatible with all versions of Prisma Agents for macOS. Using incompatible configuration profiles will cause Endpoint DLP network extension pop-up dialogs to appear on endpoints (PANG-10062).

    Changes to Default Behavior in Prisma Agent 25.4

    Review the changes to default behavior in Prism Access Agent 25.4.

    Changes in Default Behavior for Enhanced Anti-Tamper Protection

    The enhanced anti-tamper protection introduces several changes to default behavior that affect how administrators configure and users interact with protected Prisma Agents. These changes apply only to Strata Cloud Manager Managed Prisma Access. Panorama Managed Prisma Access and NGFW still use the previous anti-tamper implementation.
    • The system now provides several types of passwords users can enter depending on their intended action—the Privileged Access Token serves as the emergency password, the Privileged Access one-time password (OTP) for executing privileged operations, and operation-specific OTPs for targeted operations like disabling or uninstalling the agent. This hierarchy of passwords replaces the previous single-password validation where a correctly entered password granted universal access.
    • The system automatically provides and refreshes unique OTPs per user or user group and operation type, replacing the manual password management where administrators set a single static password across all devices. The system invalidates OTPs immediately after each use, eliminating the previous behavior where passwords remained valid indefinitely until manually changed.
    • Successful authentication with the Privileged Access Token or Privileged Access OTP now starts a configurable time window during which additional privileged operations don’t require reauthentication. The default tamper protection autoenable duration is 30 minutes. After this duration has elapsed, the anti-tamper protection will automatically reenable. The previous behavior required password entry for every privileged operation regardless of timing or previous authentication status.

    Changes in Default Behavior for Administrator-Initiated Collection of Diagnostics

    • You can now trigger diagnostic collection for specific endpoints directly from ConfigurationEndpoint Management. This replaces event-triggered diagnostic collection in the previous implementation.
    • The default diagnostic data retention period is 45 days and is configurable for up to two years. This replaces the previous fixed data retention period of 45 days.
    • The system provides delta log collection capturing incremental logs from the past 10 minutes to reduce data volume and improve collection performance. This replaces the full log collection from endpoints in the previous implementation.
    • Endpoint insights commands are no longer available in Prisma Agent 25.4. Use the Prisma Agent setup page to enable or disable endpoint insights. Use the ActionsCollect Diagnostics menu in ConfigurationEndpoint Management to trigger the collection of diagnostics on-demand.

    Changes in Default Behavior for ICMP Traffic Handling in Prisma Agent

    Starting with Prisma Agent version 25.4, the default behavior for ICMP traffic has changed, and you should be aware of this change when planning your upgrade strategy.
    In previous versions of Prisma Agent (< 25.4), ICMP traffic was blocked by default. However, with Prisma Agent version 25.4, ICMP traffic is now allowed direct by default.
    With Strata Cloud Manager R4, you gain granular control over this behavior through new configuration options. You can use Block Non-TCP and Non-UDP based traffic when connected to tunnel to block all non-TCP and non-UDP traffic. When you select this option, an additional setting Allow ICMP for troubleshooting becomes available, giving you control over ICMP traffic specifically while other non-TCP or non-UDP traffic remains blocked.
    To maintain control over ICMP traffic behavior, you should follow a specific upgrade sequence:
    1. Upgrade Strata Cloud Manager to R4.
    2. Configure the Block Non-TCP and Non-UDP based traffic when connected to tunnel and Allow ICMP for troubleshooting in the Forwarding Profiles Setup in Strata Cloud Manager to match the desired behavior.
    3. Upgrade Prisma Agent to version 25.4.
    This sequence ensures you have the configuration options available before the agent behavior changes, enabling you to block ICMP traffic if your security policies require it.
    This change provides you with broader flexibility and control over all non-TCP and non-UDP traffic. Once you have fully upgraded to both Strata Cloud Manager R4 and Prisma Agent 25.4, you can block non-TCP and non-UDP traffic and independently control ICMP traffic based on your operational needs. When you choose to block non-TCP and non-UDP traffic, you still have the option to selectively allow ICMP for troubleshooting purposes.
    Review your current security policies regarding ICMP traffic and plan your upgrade strategy to ensure continuity with your organization's requirements.

    © 2026 Palo Alto Networks, Inc. All rights reserved.