This guide covers two things:
1. How to capture Palo Alto Networks session logs with enough detail to convert them into IPFIX biflow-style session rows.
2. How to make AI-related sessions easier to isolate on NGFW, Panorama-managed environments, Prisma Access, and AI Runtime Security deployments.
The companion script, palo_alto_ai_to_ipfix.py, maps Palo Alto traffic log fields into these IPFIX-style biflow columns:
The Palo Alto traffic log reference documents these field meanings, including `bytes_sent`, `bytes_received`, `packets_sent`, `packets_received`, `session_start_time`, and `total_time_elapsed`.
Sources:
For AI session observability, the cleanest path is:
1. Enable Traffic logging on the security rules that permit outbound SaaS and AI traffic.
2. Forward those Traffic logs to Strata Logging Service, Panorama, syslog, or HTTPS.
3. If you use SaaS Security Inline or AI Runtime Security, enable the product-specific features that enrich AI visibility.
4. Export the resulting Traffic logs as CSV, JSON, or JSONL and feed them to the converter.
On the rule that allows AI application traffic:
1. Open the Security policy rule.
2. Under `Actions`, select the Log Forwarding profile.
3. For Traffic logs, enable `Log At Session End`.
4. Enable `Log At Session Start` only when you explicitly need early visibility into short-lived or long-lived sessions and accept the extra log volume.
Palo Alto explicitly notes that `Log At Session Start` consumes more resources than logging only at session end, and recommends both start and end logging mainly for troubleshooting and long-lived sessions. Palo Alto also notes that very short-lived sessions may require session-start logging to be visible.
Sources:
You have three practical collection options:
If you want SaaS Security Inline features to work properly, Palo Alto says Traffic and URL logs must be forwarded to Strata Logging Service at minimum.
Source:
Make sure your exported log stream contains at least:
If present, also keep:
Those fields improve AI-session identification.
If your environment uses SaaS Security Inline, Palo Alto documents that:
On PAN-OS 11.2, `Device > Setup > ACE` includes additional options that increase what PAN-OS logs to Strata Logging Service:
Palo Alto says session tracking was introduced in PAN-OS 11.2.5 and logs additional user and tenant information to Strata Logging Service, improving user-account-level granularity for a subset of supported SaaS applications.
Sources:
The Traffic HTTPS field reference includes:
If your exported traffic logs include those fields, use them as the highest-confidence signal that the session is AI-related. The converter does that first, before falling back to application-name heuristics.
Source:
If you use Prisma AIRS AI Runtime Security:
1. Create an `AI Security Profile`.
2. Attach it to the security policy rule that covers traffic between AI applications and AI model endpoints.
3. If you need protection for custom model endpoints, enable `Custom Model Support` and make sure the destination scope of the policy includes those endpoints.
Palo Alto states that AI security logs are generated when threats are detected, and recommends `Firewall/AI Security` logs when using Strata Logging Service. These logs are complementary to Traffic logs. They are not a replacement for Traffic logs if you want biflow/session volume analytics, because AI Security logs are threat-centric rather than per-session byte and packet counters.
Sources:
Prisma Access is covered by the same SaaS visibility pattern as NGFW for this use case:
Palo Alto’s SaaS App-ID Policy Recommendation documentation explicitly lists both `Prisma Access` and `Next-Generation Firewall` as supported environments.
Source:
Panorama is the right control point for:
For AI Runtime Security, Palo Alto says Panorama deployments without Strata Logging Service should use `Threat` logs with subtype `ai-security`. With Strata Logging Service, use `AI Security` logs for richer AI-specific details.
Source:
To keep data volume reasonable while still capturing AI sessions:
1. Create dedicated allow rules for sanctioned AI apps or AI destination groups where possible.
2. Enable `Log At Session End` on those dedicated rules.
3. Add `Log At Session Start` only on the subset where you care about short-lived prompts, frequent API calls, or long-lived sessions.
4. Forward those logs through a dedicated Log Forwarding profile so they are easy to export.
5. If possible, separate generic web traffic from AI/SaaS traffic in policy so your session dataset is cleaner.
Example with exported CSV:
python .\palo_alto_ai_to_ipfix.py .\traffic_export.csv
Example with exported JSON and extra keywords:
python .\palo_alto_ai_to_ipfix.py .\traffic_export.json --keyword "azure-openai" --keyword "vertex-ai"
Example to keep every traffic session, not just AI sessions:
python .\palo_alto_ai_to_ipfix.py .\traffic_export.csv --include-non-ai