AI-Powered Security
Prisma AIRS — AI Runtime Security Overview 18
Learning objectives
- Explain what Prisma AIRS protects that traditional NGFW inspection doesn't
- Name its three functional pillars: Discovery, Deploy, Defend
- Understand how it relates to (and extends beyond) CN-Series/NGFW licensing
Prisma AI Runtime Security (AIRS) is Palo Alto Networks' security layer purpose-built for AI applications, models, and agents — the traffic and risks it addresses (prompt injection, model/data exfiltration, insecure AI-agent tool use) sit above what App-ID/Content-ID were designed to classify.
Why
Organizations are rapidly standing up LLM-backed apps, copilots, and autonomous agents — often outside the visibility of the network security team ("shadow AI"). These systems introduce new attack surface (prompt injection, jailbreaks, sensitive data leaking into or out of a model, malicious tool/plugin calls by an agent) that traditional firewall signatures were never designed to catch.How
AIRS is organized around three pillars, and the order they're named in isn't arbitrary — it's the actual sequence a security team has to work through, because each one is a prerequisite for the next:
- Discover — "what AI even exists here?" You cannot write policy against something you don't know is running. This pillar builds the inventory: which apps, models, and agents exist, and what data/tools each one touches.
- Deploy — "where does enforcement actually go?" Once the inventory exists, each AI integration needs an actual enforcement point put in front of it — and because AI traffic doesn't all take the same path (some crosses the corporate network egress, some is pure application-to-API calls that never touch a network chokepoint), the right control point differs per integration: API-based inline scanning for AI app traffic that bypasses the network entirely, or firewall/subscription-based enforcement layered onto traffic that already passes through NGFW/CN-Series.
- Defend — "now that enforcement is in place, what does it actually catch?" The runtime protection itself: prompt injection, sensitive-data leakage, malicious/toxic model output, and abusive agent behavior.
Skipping straight to Defend without Discover/Deploy first is exactly the trap: you can have a defense engine ready to go, but with no idea what AI traffic exists or where to put it in front of, you have nothing to actually apply it to.
Diagrams: Palo Alto Networks Learning Center, Software Firewall course: Prisma airs ai runtime security defend. Click an image to enlarge.
Pros
- Purpose-built for AI-specific risk classes that App-ID/Content-ID signatures don't model
- Discovery closes the "shadow AI" visibility gap most security teams currently have
- Fits into the same Palo Alto management/licensing ecosystem instead of a bolt-on point product
Cons
- Separate product/licensing track from core NGFW subscriptions — another thing to budget and operationalize
- Fast-moving space: AI attack techniques (and the detections for them) evolve much faster than traditional malware signatures
- Effectiveness depends on actually integrating it into AI app/agent pipelines, not just deploying it and expecting network-level coverage
Exam Trap
Don't assume App-ID/Content-ID subscriptions already cover AI traffic — Prisma AIRS is a separate product/licensing track, not a feature flag inside existing NGFW subscriptions. Questions that imply "just enable a Threat Prevention setting" for AI risk are testing this distinction.
Self-check: Prisma AIRS Overview
Curriculum: Software Firewall (NGFW) course, "Prisma AIRS" lesson. Not covered in the local PAN-OS/NGFW docs mirror (separate product docs set) — summarized from Palo Alto Networks' published Prisma AIRS positioning.
AI Runtime Security: Discovery 19
Learning objectives
- Explain what "AI asset inventory" means in this context
- Describe how Discovery finds AI usage without prior instrumentation
You can't secure what you don't know exists — Discovery builds the inventory of AI applications, models, datasets, and agents in use across the environment before any policy is applied.
Why
AI adoption is frequently bottom-up: individual teams wire in a hosted LLM API or spin up an internal copilot without a formal security review. Without discovery, the first the security team learns about a given AI integration is often during an incident.How
Why "passive" is the operative word. Discovery doesn't ask teams to register their AI usage or run a scanner against a known list of assets — that would only find AI usage someone already told you about, which misses exactly the shadow-AI usage this pillar exists to catch. Instead it watches traffic and usage patterns that are already crossing monitored network and API paths — calls to known LLM/AI-provider endpoints, internal model-serving traffic, agent tool-call patterns — and infers AI usage from what it observes, the same way User-ID infers identity from login events rather than requiring every user to self-report.
What it produces from that observation. For each piece of AI usage it spots, Discovery classifies which model/provider is involved, what kind of data is flowing to it, and which internal systems or agents are initiating the calls — building this into a continuously updated AI asset inventory. "Continuously updated" matters here specifically because AI adoption is bottom-up and ongoing: a team spinning up a new integration next month should show up in the inventory without anyone re-running a one-time audit.
That inventory is exactly what Deploy and Defend are built against — without it, those later stages would be guessing at scope instead of targeting known integration points.
Pros
- Surfaces unsanctioned/shadow AI usage without requiring every team to self-report
- Feeds directly into policy scoping for the Deploy and Defend stages
Cons
- Purely passive discovery can miss AI traffic that never traverses an inspected path (e.g. a laptop calling a SaaS LLM API off-network)
- Classifying "what data went to the model" accurately still depends on decryption/visibility being in place upstream
Exam Trap
Discovery is passive/observational, not a scanner you point at an inventory — it builds its picture from traffic and usage patterns it can actually see. Traffic that never crosses a monitored path (an off-network laptop hitting a SaaS LLM directly) will not show up, no matter how long Discovery runs.
Self-check: AI Runtime Security — Discovery
Curriculum: Software Firewall (NGFW) course, "Prisma AIRS AI Runtime Security Discovery" lesson.
AI Runtime Security: Deploy 20
Learning objectives
- Compare API-based inline scanning vs. network-path enforcement for AI traffic
- Identify which control point fits which AI use case
Once you know what AI usage exists, Deploy is about putting an actual enforcement point in front of it — chosen based on whether the traffic already flows through the network perimeter or lives entirely inside an application's own API calls.
Why
Not all AI traffic looks the same: some goes through the corporate network egress where NGFW/CN-Series already sit, but a lot of it is application-to-model API traffic (e.g. a backend service calling a hosted LLM API directly) that never touches a traditional network chokepoint.How
The choice of control point comes down to one question: does this AI traffic actually cross a network chokepoint the firewall can see, or does it live entirely inside an application's own code path?
- Network-path enforcement — "the traffic already crosses infrastructure we control." If AI traffic already traverses NGFW/CN-Series — a corporate copilot whose calls egress through the normal network path, say — AI Runtime Security policy simply rides along that existing inspection path as an extension of Content-ID-style enforcement. No new infrastructure needed; it reuses the chokepoint that's already there.
- API-based inline scanning — "the traffic never touches infrastructure we control." A backend service calling a hosted LLM API directly, from inside a cloud VPC with no firewall in the path, generates traffic that's structurally invisible to any network-based control — there's no wire to inspect it on. For this case, the integration has to sit directly inside the application or agent's own request-response pipeline (prompt in, model response out), inspecting and acting on the data at the application layer instead of the network layer. This is fundamentally different work from flipping on a firewall feature: it requires the team that owns that application's code to actually wire the integration in.
Most real environments need both simultaneously, because different AI integrations across the org will fall on different sides of that "does it cross our network" question — which is exactly why Discover has to run first, to know which mode each integration actually needs.
Pros
- Two deployment modes cover both network-path and pure-API AI integrations
- Reuses existing NGFW/CN-Series inspection points where AI traffic already crosses them
Cons
- API-based scanning requires development effort to integrate into each AI app/agent's pipeline — it isn't "set and forget" like a network ACL
- Coverage is only as complete as the inventory of integration points from Discovery
Exam Trap
"Deploy" here means choosing/placing the enforcement control point (network-path vs. API-based), not installing the product. A question describing an app that talks to an LLM API directly, with no network chokepoint involved, is pointing at API-based inline scanning — not NGFW/CN-Series policy.
Self-check: AI Runtime Security — Deploy
Curriculum: Software Firewall (NGFW) course, "Prisma AIRS AI Runtime Security Deploy" lesson.
AI Runtime Security: Defend 21
Learning objectives
- Name the main AI-specific threat classes AIRS Defend targets
- Explain how runtime defense differs from static model/app review
Defend is the real-time enforcement stage: once traffic is flowing through a Deploy control point, Defend inspects prompts and model responses for AI-specific threats and blocks or sanitizes them before they reach the user or the model.
Why
An LLM-backed app has attack surface a traditional web app doesn't: an attacker can manipulate the model's behavior through crafted input (prompt injection/jailbreaks), the model can be tricked into leaking sensitive training or context data, and an autonomous agent with tool access can be manipulated into taking harmful actions. Static, pre-deployment review can't catch attacks that only appear at inference time.How
Why both directions need separate inspection — one engine watching only the input isn't enough. An AI conversation has two attack surfaces, not one, and they're different kinds of risk that need different checks:
- Inbound prompts — checked for injection/jailbreak attempts (input deliberately crafted to override the model's intended behavior or safety constraints) and other malicious payloads riding in as user input.
- Outbound model responses — checked separately, because even a perfectly legitimate-looking prompt can produce a harmful response: sensitive-data leakage (the model repeating something from its training data or context it shouldn't), toxic/harmful content, or malicious links/code the model was tricked into generating. Filtering only the prompt side would miss all of this — the exam trap here specifically calls out that half-the-picture mistake.
Why agents need a third, different kind of check beyond text filtering. An AI agent isn't just producing text — it can actually take actions through tool/API access (closing tickets, sending emails, modifying records). A successfully manipulated agent isn't just a bad-text problem, it's a real-world-consequences problem. So Defend extends past inspecting prompts and responses to actually policing which tool calls and actions an agent is permitted to take — the point being to reduce the blast radius of a manipulated agent even if the manipulation itself briefly succeeds, rather than relying on text filtering alone to prevent every possible manipulation.
Why this has to run at inference time, not just before deployment. Prompt injection and jailbreak attempts are crafted against live input in real conversations — they don't exist as a fixed artifact you could review before the model ever ships. A static, pre-deployment review of the model has nothing to inspect for an attack that only comes into existence the moment someone types it.
Pros
- Runtime inspection catches attacks that only manifest at inference time, not just at model training/review time
- Covers both prompt-side and response-side risk, plus agent tool-call behavior
Cons
- Prompt-injection detection is inherently adversarial and probabilistic — expect false negatives against novel techniques, similar to early-stage IPS signatures
- Aggressive blocking can degrade legitimate AI-app functionality if tuned too tightly
Watch: short GUI walkthroughs
Clips from the Palo Alto Networks Learning Center. They load only when you press play.
Exam Trap
Defend inspects both directions — prompts going in AND model responses coming out, plus agent tool-calls. A question that only mentions filtering user input is describing half the picture; don't pick an answer that ignores response-side leakage or agent action policing.
Self-check: AI Runtime Security — Defend
Curriculum: Software Firewall (NGFW) course, "Prisma AIRS AI Runtime Security Defend" lesson.
Module Quiz
1. A security architect asks why the organization's existing, fully-licensed Threat Prevention and Content-ID subscriptions won't cover a new internal LLM copilot's risk surface. What is the correct explanation?
2. In what order does Prisma AIRS's functional lifecycle proceed, and what does each stage answer?
3. A finance team quietly wires a spreadsheet-summarization tool to a hosted LLM API without informing the security team. Months later, the security team learns of it only through Prisma AIRS reporting rather than an incident. Which pillar is responsible for this visibility?
4. An unmanaged laptop on a coffee-shop network is used to query a personal AI chatbot for company work, entirely off the corporate network. Why does Discovery fail to surface this usage?
5. A backend microservice inside a VPC calls a hosted LLM API directly over the internet, with no NGFW or CN-Series inspection point anywhere in that path. Which Deploy control point is appropriate?
6. An internal copilot's traffic already egresses through the corporate NGFW before reaching its model backend. How does AI Runtime Security policy get applied to this traffic during Deploy?
7. Which two of the following are responsibilities of the Defend stage specifically, as opposed to Discovery or Deploy? (Choose two.)
8. An internal AI agent with access to a ticketing-system API is manipulated via a crafted prompt into attempting to close every open ticket in the queue. Which Defend capability is specifically designed to limit the blast radius of this kind of manipulation?
9. A security engineer notes that prompt-injection detection, much like early-generation IPS signature matching, will inevitably have false negatives against brand-new attack techniques. Why is this an inherent property of the detection rather than a configuration gap?
10. A customer already has Advanced Threat Prevention licensed on their NGFW fleet and assumes Prisma AIRS protection is included automatically. Is this assumption correct?
11. Prisma AIRS structures AI Runtime Security around three pillars: Discovery, Deploy, and Defend. Why must Discovery run before policy is written in Deploy/Defend, rather than after?