Index › AI-Powered Security
Revision Guide · Certified Next-Generation Firewall (NGFW) Engineer

AI-Powered Security

← Back to full guide index

~6 min read
Prerequisites: Threat & Content Services — Prisma AIRS extends the same inspection philosophy to AI/LLM traffic.

Prisma AIRS — AI Runtime Security Overview 18

Software Firewall (NGFW) course · Prisma AIRSSeparate product line

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 that map to a lifecycle: Discover the AI footprint (which apps, models, and agents exist, and what data/tools they touch), Deploy protection at the right control point (API- based inline scanning for AI app traffic, or firewall/subscription-based enforcement for traffic that already passes through NGFW/CN-Series), and Defend at runtime against prompt injection, sensitive-data leakage, malicious/toxic model output, and abusive agent behavior.
Prisma AIRS Discover, Deploy, and Defend pipeline securing AI apps, models, and agents.
Prisma AIRS Discover, Deploy, and Defend pipeline securing AI apps, models, and agents.

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
Q1. A backend engineer wires a microservice directly to a hosted LLM API, bypassing the corporate proxy. Why won't App-ID/Content-ID alone catch a prompt-injection attempt in that traffic?
A: App-ID/Content-ID classify applications and scan for known malware/exploit/URL signatures — they weren't built to parse natural-language prompts for adversarial intent. That's the AI-specific risk class Prisma AIRS Defend targets, and if the call never traverses an inspected network path, it needs the API-based Deploy integration to see it at all.
Q2. What are AIRS's three functional pillars, and what does each answer?
A: Discover (what AI assets/usage exist), Deploy (where to put the enforcement point), Defend (what to do with prompts/responses at runtime).

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

Software Firewall (NGFW) course

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

Discovery passively identifies AI-related traffic and usage patterns (calls to known LLM/AI-provider endpoints, internal model-serving traffic, agent tool-call patterns) crossing monitored network and API paths, and classifies what it finds — which model/provider, what kind of data is flowing to it, and which internal systems/agents are initiating the calls — to produce a continuously updated AI asset inventory that later Deploy/Defend policy is built against.
Discovery passively classifies AI traffic and usage patterns into an AI asset inventory feeding Deploy and Defend, with a blind spot for off-network traffic.
Discovery passively classifies AI traffic into an asset inventory — traffic that never crosses a monitored path stays invisible.

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
Q1. A finance team has been using a personal ChatGPT-style tool from an unmanaged laptop on a coffee-shop network to summarize spreadsheets. Will Discovery surface this usage?
A: No — Discovery works from traffic and usage patterns crossing monitored network/API paths. Usage entirely off that path (unmanaged device, non-corporate network) is invisible to it, which is exactly the kind of gap called out as a Discovery con.
Q2. Why does Discovery need to run before Deploy/Defend policy is written, rather than after?
A: Deploy/Defend need to know what AI assets, models, and integration points exist and where the enforcement point should sit — Discovery produces that asset inventory, so writing policy first would mean guessing at scope instead of targeting it.

Curriculum: Software Firewall (NGFW) course, "Prisma AIRS AI Runtime Security Discovery" lesson.

AI Runtime Security: Deploy 20

Software Firewall (NGFW) course

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

For traffic that already traverses NGFW/CN-Series, AI Runtime Security policy rides along the existing inspection path as an extension of Content-ID-style enforcement. For application-level AI calls that bypass the network path, an API-based inline scanning integration sits directly in the application/agent's request-response pipeline (prompt in, model response out) so it can inspect and act on traffic that never appears on the wire in an inspectable form.
Deploy places enforcement either on the existing NGFW/CN-Series network path or via API-based inline scanning for traffic that bypasses it, both feeding into Defend.
Deploy chooses the control point: network-path enforcement or API-based inline scanning, both feeding Defend.

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
Q1. Two systems need AI Runtime Security coverage: (1) an internal copilot whose traffic egresses through the corporate NGFW, and (2) a backend service calling a hosted LLM API directly over the internet from inside a VPC with no firewall in the path. Which Deploy mode fits each?
A: (1) rides along the existing NGFW/CN-Series inspection path as an extension of Content-ID-style enforcement. (2) needs API-based inline scanning integrated directly into that service's request/response pipeline, since there's no network chokepoint to enforce at.
Q2. Why is API-based scanning described as requiring "development effort," unlike a firewall ACL?
A: It has to be integrated directly into the application or agent's own prompt/response pipeline by the team that owns that code — it isn't something the network team can enable purely from the firewall side.

Curriculum: Software Firewall (NGFW) course, "Prisma AIRS AI Runtime Security Deploy" lesson.

AI Runtime Security: Defend 21

Software Firewall (NGFW) course

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

Defend inspects both directions of the AI conversation: inbound prompts for injection/jailbreak attempts and malicious payloads, and outbound model responses for sensitive-data leakage, toxic/harmful content, and malicious links or code the model may have been tricked into producing. For AI agents with tool/API access, it extends to policing which tool calls and actions an agent is permitted to take, reducing the blast radius of a successfully manipulated agent.
Defend inspects inbound prompts and outbound model responses, plus polices agent tool calls, producing an allow/block/redact verdict.
Defend inspects both directions of the AI conversation plus agent tool calls, producing an allow/block/redact verdict.

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

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
Q1. An internal AI agent with access to a ticketing-system API is manipulated via a crafted prompt into attempting to close every open ticket. What Defend capability is meant to reduce the impact of this?
A: Policing which tool calls and actions an agent is permitted to take — Defend extends beyond prompt/response text inspection to constrain what a compromised or manipulated agent can actually do via its tool access.
Q2. Why can't a static, pre-deployment model review substitute for Defend's runtime inspection?
A: Prompt injection, jailbreaks, and data-leakage attempts are crafted at inference time against live input — they don't exist yet at the point a model is reviewed before deployment, so only runtime inspection can catch them.

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?

Prisma AIRS is purpose-built for AI-specific risk classes — prompt injection, model/data exfiltration, and agent tool misuse — that sit above what App-ID/Content-ID signatures were ever designed to model.

2. In what order does Prisma AIRS's functional lifecycle proceed, and what does each stage answer?

AIRS is organized as Discover (build the AI asset inventory), Deploy (place the right enforcement control point), then Defend (runtime inspection and blocking) — in that order, since each stage depends on the previous one's output.

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?

Discovery passively identifies AI-related traffic and usage patterns across monitored paths, closing exactly this kind of "shadow AI" visibility gap without requiring any team to self-report.

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?

Discovery builds its inventory purely from traffic and usage patterns it can observe on monitored paths — usage that never crosses one of those paths, such as an off-network device on an uncontrolled network, stays invisible regardless of how long Discovery runs.

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?

Traffic that never touches a traditional network chokepoint has to be inspected via an API-based inline scanning integration built directly into the application or agent's own prompt/response pipeline — a network-side control point simply never sees it.

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?

When AI traffic already flows through NGFW/CN-Series, Deploy reuses that existing inspection point instead of requiring a separate control point, layering AI-aware enforcement onto the same path.

7. Which two of the following are responsibilities of the Defend stage specifically, as opposed to Discovery or Deploy? (Choose two.)

Defend is the runtime enforcement stage: it inspects prompts and model responses for AI-specific threats and constrains agent tool/action use. Building the asset inventory is Discovery's job, and choosing the enforcement control point is Deploy's job.

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?

Defend extends beyond inspecting prompt and response text to actively policing what actions a manipulated agent can take through its tool access, directly limiting the impact of this kind of attack.

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?

Like early-stage IPS signature matching, prompt-injection detection is adversarial by nature — attackers actively craft novel bypass techniques, so some false-negative rate against unseen attacks is expected rather than a sign of misconfiguration.

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?

Prisma AIRS sits on a distinct product and licensing track from core NGFW subscriptions like Threat Prevention or Advanced Threat Prevention — it must be separately budgeted and operationalized, not assumed to be bundled in.
← Threat & Content ServicesAccess & Identity →