Display Insights Using API Violations View
Focus
Focus
Prisma AIRS

Display Insights Using API Violations View

Table of Contents

Display Insights Using API Violations View

Learn about view Prisma AIRS Violations View.
Where Can I Use This?What Do I Need?
  • Prisma AIRS AI Runtime Security
The Prisma AIRS API Violations View provides insight into specific instances of atomic synchronous API scans identified as threats and subsequently blocked. This view presents individual API calls containing detected threats, offering a focused perspective on security incidents within your AI applications. It serves as your primary interface for understanding and investigating blocked API traffic, which Prisma AIRS defines as violations.
Prisma AIRS processes your API traffic using a hierarchical data model. Your Tenant Service Group (TSG) in Strata Cloud Manager (SCM) contains applications, each generating sessions of API calls. Individual scan requests within these sessions are the atomic units of API calls that undergo security analysis.
Your associated security profile dictates which detection services, such as Prompt Injection, URL Filtering, and Data Leak Detection, analyze various payload types within the scan request. A violation occurs when any detection service returns a malicious verdict, triggering a "Block" action for that specific scan request. Logs are generated for these verdicts, providing detailed records for your investigation.
The Violations View feature provides the following benefits:
  • Focused investigation – Investigate the highest risk API violations to protect your environment.
  • Detection efficacy validation – Determine the effectiveness and accuracy of Prisma AIRS detections in your network.
  • Hardened AI security posture – Strengthen the security posture of your AI applications, models, and agents.
  • Comprehensive API threat visibility – Gain visibility into the nature and scope of API threats targeting your AI infrastructure.
  • Streamlined analyst workflow – Provide your security analysts with critical insights to perform daily threat investigation tasks.
Limitations / Scope
The Prisma AIRS Violations View has specific boundaries and current constraints. Understanding these limitations helps you set accurate expectations for the feature's capabilities in your environment.
Use the Violations View exclusively within your Prisma AIRS API product to monitor API security threats. This feature specifically focuses on detections made by Prisma AIRS API; you will not see violation data from Prisma AIRS Network Intercept or Agent Security Fabric within this view.
Snippet Availability Limitations
Not all threat detectors currently support displaying "Violated Snippets" within the Transaction Overview flyout. While a threat may be detected and a violation recorded, the specific content snippet that triggered the detection might not be visible for certain detectors. Detectors without snippet support include:
  • contextual-grounding
  • topic-guardrails
  • agent-security
  • command-injection
For detectors without snippet support, the UI displays "Snippets are currently not supported for [detector type]" in the Transaction Overview flyout; this message applies to contextual grounding, topic guardrails and agent security detector types.
Security profile changes for Data Loss Prevention (DLP) patterns are currently not supported. This limitation exists because the configuration option for Snippet Viewing and Masking in the Data Loss Prevention section of Strata Cloud Manager (SCM) does not currently provide a toggle to Store Snippets of Sensitive Data. This functionality will be available in a future update.
Best practices/ Recommendations
Consider these factors when implementing the API Violations View in your network:
  • Prioritize Investigations – Focus on high-severity violations first to address the most critical risks to your AI applications and data.
  • Validate Detection Efficacy – Regularly review detected violations and their associated snippets to ensure Prisma AIRS detections are accurate and effective for your specific use cases.
  • Refine Security Profiles – Use insights from the Violations View to iteratively harden your AI Security Profiles, reducing false positives and strengthening overall protection.

Investigate API Security Threats Using the API Violations View

This section provides a clear, step-by-step walkthrough for using the Prisma AIRS Violations View UI to investigate and manage API security threats in your environment.
Prerequisites
  • An active Prisma AIRS API deployment integrated with your Strata Cloud Manager tenant.
  • No specific product versions or feature flags are required beyond your standard Prisma AIRS API setup.
  1. Access the API Violations page. On the left navigation bar, Select API Violations under AI Runtime. This action navigates you to the main Violations View, which serves as the central hub for threat investigation.
    Observe the Violation chart (Sankey chart) at the top of the page and the Violations Table below it. The Violation chart provides a high-level visual distribution of blocked transactions by content type, detector, and severity. The Violations Table lists individual scan requests that triggered violations.
  2. Filter violations for specific analysis.
    1. Use the filter options at the top of the page to refine the displayed violations. Filtering allows you to narrow down the scope of your investigation to focus on specific types of threats or content, making analysis more efficient.
    2. Select Content Type (for example, Prompt, Code, Model Response, Tool call) from the drop-down menu. This filter helps you identify violations originating from specific parts of an API interaction, such as user prompts or model responses. Note that a prompt might contain embedded code, leading to code-related violations even when you filter by Prompt.
      A prompt might contain embedded code, leading to code-related violations even when you filter by Prompt.
    3. Select Threat Type (for example, Prompt Injection, Data Leak, URL Security) from the drop-down menu. This filter allows you to focus on specific categories of security threats detected by Prisma AIRS.
    4. Select Severity (for example, Critical, High, Medium, Low) from the drop-down menu. You can prioritize investigations by focusing on violations with higher severity levels, indicating a greater potential risk to your systems.
    Observe how the Violation chart and Violations Table dynamically update based on your selected filters. The real-time updates provide immediate feedback, allowing for interactive exploration and drill-down into the data.
  3. Investigate a specific violation using the Transaction Overview flyout. In the Violations Table, Select the hyperlinked Scan ID for the violation you wish to examine in detail. Selecting the Scan ID opens a side panel (flyout) that provides granular details about that specific API scan request and its associated violations.
    1. Review the Transaction Overview panel.
      Observe the Violation Metadata section, which includes details such as Timestamp, Session ID, App name, Model Name, and Security Profile Name. This metadata provides essential context about when, where, and under what security policy the violation occurred.
      View the Count of policy violations by severity for this specific scan. This count summarizes the total number of individual detections (violations) within this single scan request, categorized by their severity.
    2. Examine the Threat Snippets & Payload by Content Type section. This section provides the critical evidence (snippets) that triggered the detection, helping you understand the exact nature of the threat to your systems:
      • Expand the accordion for each detector that fired to view specific details.
      • For Prompt Injection, review the Violated Snippet (an array of strings) to see the malicious parts of the prompt. Prompt Injection snippets highlight the specific text sequences within the prompt that were identified as malicious.
      • For URL Security, observe the URL that was flagged and its associated Categories. This provides the exact URL and its classification (for example, malware, phishing) that led to the violation.
      • For Data Leak Detection (DLP), identify the Data Pattern (for example, Credit Card Number), Confidence, Pattern Type, Occurrences, and the masked Violated Snippet.
        The Violated Snippet for DLP is only visible if the Mask DLP Patterns setting is not enabled in your security profile. DLP snippets provide detailed information about sensitive data exposure, including the type of data, the system's confidence in its detection, and the number of times it appeared. The masking setting protects sensitive information from being fully displayed.
      • For violations within a Tool content type, note the additional metadata such as Tool Name, Direction, Ecosystem, Method, and Server, alongside the violated snippet. This context is crucial for understanding threats that originate from or target specific tools used by the AI application.
        If a snippet is not available for a detector, the UI will indicate No snippet available. This message clarifies that while a threat was detected, the system does not currently support displaying the specific snippet for that detector.
  4. Understand complex scan requests with multiple violations:
    1. Observe the Violation Severity Breakdown pop-over by hovering over the info icon in the Violations Table for a single scan request that triggered multiple threat detectors across different content types. This pop-over consolidates and displays all individual violations for a single, complex transaction, providing a comprehensive view of all threats detected within that request.
    Note how the UI aggregates and displays all violations for a single, complex transaction, even if they span different content types and detectors. This aggregation simplifies the analysis of multifaceted attacks or misconfigurations by presenting all relevant threat information for one transaction in a unified manner.

View Transaction IDs

You can track individual API transaction independently from session-level grouping by viewing transaction IDs. The transaction_id field coexists with legacy session_id and tr_id fields, providing the flexibility to provide all three IDs simultaneously without conflict.
Prior to this enhancement, any API key could call scan and report APIs to scans and reports from any API key. With this update the API key must be associated to the app that is associated to the scan and report.
The configuration of this feature is primarily handled through the API request structure. To utilize the new tracking capabilities provided by the transaction ID enhancement, you should update your API implementation as follows:
  1. Update the API request. You can now include a new transaction_id field in your ScanRequest. Include the field name: transaction_id; this must be a string with a maximum length of 100 characters. You can provide this alongside existing session_id and tr_id fields without conflict.
  2. Determine implementation logic. The system handles the configuration of this ID based on whether you provide it or not:
    1. Custom ID: If you provide a value (e.g., "custom_tx_12345"), the system will store it in the session_transaction_id database column and echo it back in all responses.
    2. Auto-Generation: If you omit the transaction_id field, the service will automatically generate one for you using a pan_ prefix.
  3. Verify the response. Once configured in your request, you should update your downstream logic to capture the ID from any of the following response points:
    1. Sync Scan API Response: The transaction_id field is echoed here.
    2. Scan Results API: Included in the result block.
    3. Scan Reports API: Included in the top-level report structure.
    4. PubSub Messages: If you consume downstream data, look for the session_transaction_id field in the message schema.
    If you provide both session_id and tr_id in a request, the legacy behavior still applies where session_id takes priority and the tr_id response will echo the session_id value. The new transaction_id remains completely unaffected by this logic.
    To configure transaction IDs, you need to include the new transaction_id field in your JSON request body when calling the Scan API. Below are the three primary ways to implement this depending on your tracking needs.
    Custom Transaction Tracking
    Use this configuration if you have an internal correlation ID or unique identifier from your own system that you want to map to the scan.
    { "transaction_id": "my-internal-tx-999", "session_id": "user-session-abc", "tr_id": "legacy-id-123", "ai_profile": { "profile_name": "my-profile", "contents": [ { "prompt": "Analyze this data." } ] } }
    The system accepts your custom string (up to 100 characters) and echoes it back in all response types.
    Mixed Legacy and New Tracking
    This configuration shows how the new field remains independent. Even if you use legacy fields, the transaction_id will not be overwritten or merged.
    Request
    { "transaction_id": "tx_alpha_1", "session_id": "session_123", "tr_id": "different_id_456" }
    Response Mapping
    | Field | Value | Logic | | :--- | :--- | :--- | | transaction_id | tx_alpha_1 | Stored in session_transaction_id column. | | session_id | session_123 | Stored in transaction_id column. | | tr_id | session_123 | Echoes session_id due to legacy priority rules. |
    Automated System Tracking (Default)
    If you do not include the field in your configuration, the service handles it automatically.
    Request
    { "session_id": "session_abc", "ai_profile": { ... } }
    The system auto-generates a value with a pan_ prefix (e.g., pan_550e8400...) and stores it in the database for you.
    Storage and Downstream Configuration
    When configuring your database queries or PubSub consumers to recognize these changes, note the following mapping:
    • Database Table: Look for the new column session_transaction_id (Type: STRING(100)) in the scan_request table.
    • PubSub: Ensure your downstream subscribers are updated to parse the session_transaction_id field from scan result messages.
    You can view transaction_id information using Strata Cloud Manager (SCM). On the left navigation bar, Select API Violations under AI Runtime. This action navigates you to the main Violations View, which serves as the central hub for threat investigation.
    Use the API Violations Chart to view transaction_id information:
    You can view AI Session Transaction Details within the Session Overview panel: