New Features - Prisma AIRS - June 2026

The Prisma AIRS Runtime Security API (which inspects prompts, model responses, and tool calls in real time) is introducing per-tenant rate limiting for the Scan API.

Note: Rate limiting is considered best practice to mitigate scenarios where high volume environments could degrade performance.

How it works

Rate limits are enforced across two dimensions:

• RPS (Requests Per Second) — controls call frequency

• TPM (Tokens Per Minute) — controls data volume/payload density

Both are auto-calculated based on each customer's deployment profile Monthly Billion Tokens (MBT) quota.

What happens when limits are exceeded

The API returns an HTTP 429 Too Many Requests error. Callers (apps, gateways, agents) need to handle this gracefully. Note that even if the overall rate hasn't been reached, bursty traffic may also be throttled — Palo Alto Networks recommends distributed, even traffic.

Overrides

If your environment exceeds the 150 RPS / 15M TPM maximums you’ll need to contact Palo Alto Networks Support.

Ensure all prerequisites are met prior to initiating the rate increase request process. Requests that do not meet these conditions will be returned to the customer for correction.

• [ul]Rate increases may only be requested after the customer has purchased tokens.

• Requests must be limited to detection services that are already enabled in the customer's profile.

• Note that some detection services have a greater impact on overall system capacity than others.

Before beginning this process, confirm that you meet all prerequisites described above.

1. Submit a rate increase request. You must officially ask for a rate increase; raise a support case and communicate with your account team.
2. The request must include all of the following information:
   • The type of limit to change: lower or upper limit, and whether it is RPS or Token-based.
   • The list of detection services that you have enabled and are actively using

Prisma AIRS AI Red Teaming now offers configurable target profiling, giving you direct control over when and whether automated target profiling runs against your AI endpoints. Previously, target profiling ran automatically upon adding a target. Now you can enable profiling immediately when adding a target, or disable it and run it later.

The target addition workflow now includes a configurable target profiling option that you can enable or disable. Enabling this option preserves the existing automatic profiling behavior; disabling it defers profiling until you are ready to run it. You can also trigger profiling at any time using the Run Profiling option from the target profile flyout. Additionally, the target overview page now displays a Target State that reflects each target's current status, ranging from draft through active, profiling in-progress, profiling complete, partially profiled, or profiling failed, giving teams at-a-glance visibility into target and profiling readiness across all targets.

When adding or editing a target, the new Target Profiling toggle (enabled by default) appears in the target background section. Disabling the toggle skips profiling and allows you to initiate it later from the target profile flyout or the target overview page. When launching an agent-led scan on an unprofiled target, a disclaimer warns that attack relevance and coverage may be reduced, with an option to run profiling first and have the scan start automatically once profiling completes. Attack Library and Custom Prompt Sets scans proceed without a disclaimer regardless of profiling status.

If you manage multiple AI endpoints and want to control when profiling traffic reaches your systems, the target profiling enhancement gives you that control. Teams running proof-of-concept evaluations or static-only scans can defer profiling entirely, reducing time to first scan and avoiding unnecessary token consumption. For teams running agent-led attacks, the scan flow ensures you are informed about profiling status before launching and supports on-demand profiling. The target state information on the Target page makes it straightforward for security teams to track which targets are fully profiled, which need attention, and which are still being configured.

This feature introduces a single image that consolidates VM-Series and AI Runtime Firewall (AIRS VM) functionalities into a single software version. This unified image streamlines deployment and management by allowing a single base image to operate as either a VM-Series firewall or a AI Runtime Firewall (AIRS VM) instance, with the operational mode dynamically determined by the applied license. This enables a seamless runtime model update from VM-Series to AI Runtime Firewall (AIRS VM) without requiring a disruptive reboot.

The following are the benefits of migrating VM-Series to AI Runtime Firewall (AIRS VM) using the single image:

• Seamless Transition – Migrate your firewall operating modes (VM-Series to AI Runtime Firewall (AIRS VM) without requiring a disruptive reboot.

• Flexible Deployment – Adapt to evolving needs by migrating entire deployment profiles.

• Simplified Management – Consolidate VM-Series and AI Runtime Firewall (AIRS VM) into a single image for easier deployment and upgrades.

• Optimized Resource Utilization – Leverage licensing to dynamically determine firewall mode, potentially optimizing credit consumption.

Prisma AIRS AI Red Teaming now supports multilingual security assessments, enabling organizations to test how their AI models respond to adversarial inputs in languages other than English. We've newly added support for French, Japanese, Thai, and Hindi languages.

Security alignment in large language models is often inconsistent across languages. A model that correctly refuses a harmful request in English may comply when the same request is made in another language. Until now, English-only scanning left organizations with multilingual or regionally deployed AI applications unable to detect these cross-lingual vulnerabilities. The multi-lingual scan support closes that gap by bringing adversarial testing to the languages where these risks are most likely to go unnoticed.

Multilingual scanning covers the same attack categories available in English-language assessments. Adversarial prompts are delivered in the selected language, and the target model's response is captured in that same language. Evaluation and insight summaries remain in English, giving security leaders a consistent view across all assessments regardless of scan language. To use multilingual scanning, select the scan language while starting a new scan. Individual scan reports display attack prompts and model responses in the native script of the selected language, while the AI Overview of Insights and LLM Generated Summary sections continue to render in English for executive review.

If your organization deploys AI applications that serve users in French, Japanese, Thai, or Hindi-speaking markets, multilingual scanning surfaces language-specific vulnerabilities that English-only testing cannot detect. This is particularly relevant for teams validating localized AI applications before regional rollout or assessing risk across international deployments from a centralized dashboard.

AI Red Teaming introduces Privilege Misuse as a new attack category under Agent Scan for agent target types. This category tests whether AI agents correctly enforce authorization boundaries when subjected to manipulation attempts by users seeking unauthorized access. Privilege Misuse aligns with Privilege Compromise (T3), Identity & Privilege Abuse, a critical vulnerability class defined in the OWASP Top 10 for Agentic Systems.

AI agents in enterprise environments operate with access to sensitive tools and data under role-based access control (RBAC). Unlike traditional applications, agents make autonomous decisions about permissible actions, which introduces the risk of a user manipulating an agent into bypassing privilege boundaries and executing unauthorized operations. Privilege Misuse testing is designed to surface these authorization gaps before they can be exploited in production.

This category evaluates whether an agent can be manipulated into performing unauthorized actions across four key areas: users claiming higher roles to access restricted functionality, accessing data belonging to other users at the same privilege level, tricking the agent into leveraging its own elevated privileges on a user's behalf, and convincing the agent to permanently elevate a user's permissions.

Privilege Misuse will be available as a new goal category under Agent Scan for agent target types. No additional configuration is required. When Auto-Generated Goals are selected during agent scan configuration, Privilege Misuse goals are automatically generated based on the roles and permissions detected in the agent's environment.

If you are deploying AI agents that serve users with different roles and permissions, Privilege Misuse testing helps you identify authorization vulnerabilities before they can be exploited in production. Whether your agents handle IT support tickets, manage financial workflows, or process customer data, this category ensures that your agents respect the access boundaries you've defined and flags where they don't.