Prisma Agent vs GlobalProtect: What Actually Changes
Prisma Agent is not GlobalProtect with a new logo: it changes where the agent is managed, how traffic is steered, and how you operate it day to day.
As project manager, I recently led a Prisma Agent 26.2 deployment on Windows and iOS endpoints, delivered with my project team. Official documentation covers the basics, but there is little practitioner writing on what actually changes for teams coming from GlobalProtect. This post is the first in a short series: here I cover the differences that matter most, and the next post covers the issues we hit in production and how we fixed them.
A note on naming: Palo Alto Networks first released the product as Prisma Access Agent, and the newest documentation calls it Prisma Agent. Both names refer to the same agent, and you will still find both in the docs and on the community forums.
This post reflects Prisma Agent 26.2 as of November 2026. The product evolves quickly, so check the release notes for your version.
Management and architecture
The biggest shift is that the agent is managed from the cloud, not from a portal on your firewall.
No more portal on the firewall
With GlobalProtect, the portal lives on a firewall and hands out configuration to the app. With Prisma Agent, configuration and lifecycle management sit in Strata Cloud Manager, on the Endpoint Management page. That holds even if you manage Prisma Access with Panorama: agent settings, forwarding profiles, authentication, and infrastructure for the agent are configured in Strata Cloud Manager (Panorama support).
In practice, this means one more console to plan for. If your team runs everything from Panorama today, budget time for SCM access, roles, and training before you start.
Forwarding profiles replace split tunneling
Everything GlobalProtect handled with split-tunnel settings is handled in Prisma Agent with forwarding profiles. Rules decide which traffic goes through the tunnel, which goes direct, and which is bypassed. The model is more flexible, but it is a different way of thinking: migrating means rebuilding your split-tunnel logic as forwarding rules, not copying it over.
It works with NGFWs too
A common misconception is that Prisma Agent only works with Prisma Access. It also supports NGFW deployments, so it is an option for organizations with on-premises gateways as well.
Coexistence with GlobalProtect
Both agents can be installed on the same endpoint during a transition, but only one can be active at a time. Users or administrators switch between them from the agent app or with the “pacli” command. This makes a phased migration possible, with GlobalProtect as a fallback for early adopters.
Security
Prisma Agent is much harder for users to disable or remove than GlobalProtect, and it brings DLP to the endpoint.
Anti-tamper that actually holds
On Windows and macOS, anti-tamper protection blocks users from deleting or renaming agent files, stopping agent services and HIP processes, and, on Windows, changing the agent’s registry keys. It also covers “pacli”: a user can’t disable the agent or the anti-tamper feature from the command line. In my experience, this is far more effective than anything GlobalProtect offers.
A controlled way to disable it
Sometimes a user genuinely needs to turn the agent off, for example to connect another VPN. GlobalProtect already covers this with disable by ticket, and Prisma Agent redesigns it to be simpler for administrators: you generate a one-time password on the Endpoint Management page in Strata Cloud Manager and share it with that user.
Endpoint DLP
Prisma Agent supports Endpoint DLP, which GlobalProtect never did. DLP rules are enforced on the device itself, not only on traffic passing through Prisma Access.
Get Emyl’s stories in your inbox
Join Medium for free to get updates from this writer.
Check licensing before you plan for it: Endpoint DLP requires a specific license, either included in CASB-X or bought separately.
Operations
Operations is where Prisma Agent pulls furthest ahead: controlled upgrades and remote troubleshooting are built in.
Staged rollouts
GlobalProtect has nothing comparable. With staged rollouts, you define up to five upgrade rings, Ring 0 to Ring 4, plus a default ring for everything else. Each ring matches users, user groups, or operating systems, with up to three criteria per ring. A typical rollout looks like this:
- Ring 0: the IT team, who test the new version first
- Ring 1: a group of friendly users who report problems quickly
- Rings 2 to 4: progressively larger groups of users
- Default ring: everyone else, plus devices that were offline during earlier rings
You get 72 hours’ notice of an upcoming rollout, and each ring has its own runtime window, so a full rollout can take weeks. If something goes wrong, you can stop the rollout: devices already upgraded stay upgraded, and a restart begins again at Ring 0 without re-upgrading them. You can also upgrade or downgrade individual devices manually from the Endpoint Management page. Staged rollouts apply to Windows and macOS only; mobile agents are updated through the app stores or your MDM.
Remote shell
From the Endpoint Management page, an administrator can open a remote shell on a Windows or macOS endpoint. The user must accept the request within two minutes; then you get a live terminal, as if you were sitting at the machine. We used it on Windows, and it changes how remote troubleshooting works: no screen sharing, no asking the user to type commands.
One warning: every command and its output are logged. Avoid typing or displaying anything sensitive during the session.
Remote diagnostics
Administrators can also collect the agent’s diagnostic logs directly from SCM, and in our deployment this worked on iOS as well as Windows. Since version 25.7, you can require user consent before collection; it is disabled by default. In Europe, privacy rules make it worth enabling.
The “pacli” command
“pacli” is the agent’s command-line tool, and it is very powerful for troubleshooting almost anything on the client. It also works inside the remote shell, which makes the two features a strong combination: open a shell, run “pacli”, and diagnose the problem in one session.
One tip: on Windows, “pacli” is often not in the system path, so typing the command alone fails. Even after the rename, the documented location is still the old folder name, so run it with the full path, or add the folder to your path:
"C:\Program Files\Palo Alto Networks\Prisma Access Agent\pacli"What GlobalProtect still does better
Prisma Agent is the future, but GlobalProtect is still the more mature product today.
- Configuration depth. GlobalProtect has years of options behind it. Practitioners on the community forums note that Prisma Agent still has fewer configuration options. In our deployment, the one gap we felt was source IP restriction for the authentication override cookie. Overall, the important features are covered; what’s missing are minor or advanced options that GlobalProtect offers.
- Documentation and community knowledge. For GlobalProtect, almost every problem has a knowledge base article or forum thread. For Prisma Agent, documentation is thinner and knowledge base doesn’t yet exists, you will often be the first to hit an issue.
- Stability. The product is not yet mature. Plan more intensive testing than you would for GlobalProtect, and be ready to work with TAC on some issues that will inevitably come up before you reach the optimal setup.
None of this is a reason to avoid Prisma Agent. It is a reason to plan the migration carefully, start with a pilot ring, and keep GlobalProtect available as a fallback during the transition.
What’s next
In the next post, I’ll go through the issues we hit during this deployment, grouped by area, with the symptom, the cause, and the fix or workaround for each. Many of them are not documented anywhere yet.
If you’re planning a GlobalProtect to Prisma Agent migration and want an independent review of your design, feel free to send me a message on LinkedIn.
