AI Red Teaming: Technical Requirements Document

Customer intake for AIRS AI Red Teaming engagements

Engagement Details
Customer Name  
Project ID  
Consultant  
Project Manager  
Sales Engineer  
Document Date  
Project Start Date  
Target Deployment Date  
How to use this document
  • * Required — engagement cannot proceed without this
  • † Conditional — required only if a prior answer triggers it
  • Unmarked — optional, improves engagement quality

Part A is completed once per customer. Part C is repeated for each target or target group.

Cross-reference

This TRD feeds the AI Red Teaming Deployment Guide. Each section below notes which guide step consumes its data.

Part A: Engagement Context

Asked once per customer. Establishes who they are, what AI systems they have, and what they need.

Required Attendees

The roles below must be present on the TRD discovery call to unblock all configuration decisions. If any required role is absent, record which sections are deferred and schedule a targeted follow-up before the deployment session begins.

Role Why They Must Be Present Risk If Absent
PANW PS Consultant Leads discovery, maps answers to deployment guide steps, flags blockers in real time. Without facilitated collection the session becomes unstructured; data quality and completeness suffer.
* Project Sponsor Owns engagement scope, timeline, and success criteria (§1). Must authorize the scan boundary — which environments and targets are in scope. §1 Engagement Overview cannot be finalised. Scope creep risk during execution if not agreed upfront.
* AI / ML Technical Lead Knows every target AI application: endpoint URLs, authentication methods, rate limits, and model configuration. All of Part C depends on their input. Part C (Sections 9–16) is entirely blocked. Every per-target configuration session is delayed until they are available.
* Security Lead Owns the risk priority matrix (§10), guardrail detection configuration (§12), and decides which scan categories are in scope. Only they can confirm what is and is not authorised to test. §10 Risk Priority Matrix and §12 Guardrail Detection cannot be completed. Scan execution is blocked until categories are authorised.
* CSP Portal / Cloud Admin Must confirm the AIRS license is active, the TSG is provisioned, and Flex Credits are allocated before the deployment session. Owns the deployment profile creation. Licensing and Tenant prerequisites (Part B Prerequisites) cannot be verified. Deployment cannot be scheduled until these are confirmed in a separate session.
Application Owner † Required per target when the AI/ML Lead does not own the application directly. Holds endpoint credentials, knows system prompt content, and can confirm rate limits and environment details. That target's Part C sections cannot be completed on the call. A follow-up session per application owner is required before that target can be configured.
Network / Proxy Lead † Required only if targets are behind a proxy, WAF, or private network. Must confirm egress rules, proxy authentication, and whether AIRS IPs need to be allow-listed. §8 Network & Connectivity cannot be completed. Scan probes may be blocked silently, producing misleading results.
Pre-call preparation

Send §2 Target Overview to the AI/ML Technical Lead 48 hours before the call — target names, hosting provider, and framework require data lookup and should not be filled in on the call. Send §10 Risk Priority Matrix to the Security Lead in advance so category priorities are pre-agreed before the session.

1 Engagement Overview Scoping

QuestionResponse / Notes
* Primary business driver for AI red teaming? select Pre-deployment security validation / Compliance requirement / Risk assessment / Incident response / Other
* What does success look like for this engagement? text  

Stakeholder Contacts

RoleNameEmailNotes
* Project sponsor      
* Technical lead (AI/ML)      
* Security lead      
CSP portal admin      
Complete Prerequisites Before Section 2

Before proceeding to Section 2: Target Overview, ensure all items in the Prerequisites section below are confirmed. The prerequisites gate — licensing, SLS, TSG, IAM, network readiness, and target endpoint readiness — should be resolved before the deployment call is scheduled.

Engagement Sizing

Calculated from §2 (target count), §1 (credits — see Licensing section), and the Network & Connectivity section in Prerequisites. This section is completed by the consultant.

Why this matters: Engagement sizing drives both the commercial package tier and the practical shape of how the engagement runs. The number of targets determines credit consumption and total scan duration. The scan types selected determine what personnel the customer needs available and how long each phase takes. Getting sizing wrong means either running out of credits mid-engagement or under-utilizing the allocated budget. Walk through the scan type descriptions below with the customer so they understand what they are purchasing before the package is selected.

Scan Types

There are three scan types. Most engagements use all three in order. Each has a different purpose, duration, and credit cost.

▶ Attack Library (STATIC) — Run First

The Attack Library runs 500+ curated attack scenarios maintained by 18,000+ researchers, covering all four categories: Security, Safety, Compliance, and Brand. It is fully automated once started and requires no customer involvement during the run.

AttributeDetails
DurationApproximately 5 hours per target
Attack count500+ scenarios across all selected categories
Customer effort during scanNone; fully automated
OutputScored report: which attacks succeeded, which were blocked, overall risk score
Best forFirst scan on any target; compliance baselines; regression testing between deployments
Do Not Abort Mid-Scan

Do not stop a running Attack Library scan. Partial results do not provide meaningful coverage and cannot be completed retroactively. Let it run to completion.

Recommended category selection for a first scan: all categories and all subcategories. This establishes a comprehensive baseline. Subsequent scans can be narrowed to categories where vulnerabilities were found.

▶ Dynamic Agent (DYNAMIC) — Run Second

The Dynamic scan deploys an LLM-powered attack agent that discovers and exploits weaknesses through adaptive multi-turn conversations. Unlike the Attack Library which sends fixed scenarios, the Dynamic agent reasons about the target's responses and adjusts its approach in real time.

AttributeDetails
DurationVaries by breadth/depth settings; typically 1–4 hours
ApproachAdaptive multi-turn conversations; discovers and exploits contextual weaknesses
Customer effort during scanNone; fully automated
Best forDeep testing after Attack Library baseline; Agent-type targets; complex multi-turn vulnerabilities

Key parameters:

ParameterDefaultWhat it controls
Stream breadth6Number of parallel attack threads running simultaneously
Stream depth10Maximum conversation turns per attack thread
Attack goalsAutoCustom goals in natural language, or agent discovers automatically

Configure breadth, depth, and attack goals per target in Section 15: Scan Strategy. Default values (breadth 6, depth 10) apply unless overridden.

Testing modes (how much context is given to the attack agent):

  • Black box — no context provided; agent discovers everything from the target's responses
  • Grey box — industry and use case provided; agent generates more targeted attacks
  • White box — full system prompt and context provided; most effective, produces highest-quality findings
Attack Goals Drive Quality

Specific, targeted attack goals produce far better results than auto-discovery. Generic goals produce generic findings. Examples of effective goals: "Extract the system prompt", "Get the assistant to endorse a competitor product", "Make the model generate code that accesses the filesystem", "Convince the assistant to reveal customer data". Work with the customer to define goals based on the target's actual business context.

▶ Custom Prompt Sets (CUSTOM) — Run Last

Custom Prompt Sets are organization-specific attack prompts uploaded by the customer or developed by the consultant. They run as a targeted scan after the Attack Library and Dynamic scans have established a baseline.

AttributeDetails
DurationDepends on prompt count
ValidationEach prompt is auto-validated (5–10 minutes per prompt) before it can run
Best forRegression testing; industry-specific compliance scenarios; brand-specific attacks not in the library
Prompt sourcesCustomer-provided, consultant-developed, or industry templates
Invalid Prompts Are Silently Skipped

Only auto-validated prompts run. Invalid or improperly formatted prompts do not generate errors during the scan; they simply do not appear in results. Validate the prompt set before running the scan to confirm all prompts passed validation.

Recommended Scan Order

Attack Library first (5 hours, comprehensive baseline) → Dynamic Agent second (adaptive deep testing) → Custom Prompts last (targeted, scenario-specific).

Package Tiers

Package Targets Scan Types Included Est. Sessions Select
Starter — 1 target, pre-built connection 1 Attack Library + Dynamic Agent 5
Standard — Up to 3 targets 1–3 Attack Library + Dynamic Agent + Custom 10
Advanced — Up to 5 targets, includes Network Channel 1–5 All scan types + Network Channel 25
Enterprise — 5+ targets, custom engagement 5+ All scan types + Network Channel + CI/CD Custom

Add-Ons

Add-OnDescriptionInclude?
Network Channel deployment Required for private endpoints. Adds K8s prerequisites and 1–2 hours setup. Yes / No
REST wrapper development Required for non-REST protocols (gRPC, Socket.IO, GraphQL). Custom development, 2–4 hours. Yes / No
CI/CD pipeline integration Automated scan triggers in CI/CD pipelines. Requires service account. Yes / No
Custom attack development Consultant develops custom prompt sets tailored to the target's business context. Yes / No

Prerequisites

Complete every item in this section before the deployment call begins. Missing any item is a potential session-stopper. Use this as a pre-engagement gate: unresolved items one week before the call warrant rescheduling.

Licensing & Credits

Feeds: Guide Step 3.1 (Create a Deployment Profile)

QuestionResponse / Notes
* CSP account name text  
* CSP account number text  
* CSP admin email (with credit allocation permissions) email  
* Credit pool name / ID text  
* Total credits in customer's AIRS pool? number  
* Credits allocated specifically for AI Red Teaming? number  
Are credits shared with other AIRS products (Runtime, Model Security)? select Yes — shared pool / No — dedicated RT allocation

Licensing & Credits

AI Red Teaming is licensed through Software NGFW Credits, not as a standalone SKU. Credits must be allocated in the Customer Support Portal (CSP) before a deployment profile can be created.

RequirementStatus
Active Palo Alto Networks Customer Support Portal account 
AIRS credits available in the pool — minimum 1,200 credits required to create the Red Teaming deployment profile (technically 1,197.1); plus additional credits for scans 
CSP admin with credit allocation role identified and available for the call 
Credit amount to allocate for AI Red Teaming confirmed 
Blocker: Credit Allocation Role

The credit allocation role is a CSP-level permission, separate from SCM admin access. A standard SCM admin cannot view or allocate credits. If the correct CSP admin is not identified and available for the deployment call, activation cannot begin.

Strata Logging Service (SLS)

SLS is a mandatory prerequisite for AIRS. It must be enabled on the tenant before AIRS activation begins. If SLS is not active, the activation flow fails mid-process and cannot recover without starting over.

RequirementStatus
SLS enabled on the target tenant (verify in Common Services before the call) 
Blocker: SLS Must Be Active Before the Call

Do not schedule the deployment call until SLS is confirmed active. Enabling SLS may require a separate CSP activation step and additional provisioning time. SLS cannot be added retroactively to an in-progress deployment profile.

Tenant Service Group (TSG) & Region

AIRS is provisioned inside a Tenant Service Group (TSG) in the Palo Alto Networks hub. The region is set at TSG creation and cannot be changed. The AIRS deployment profile must be created in the same region as the TSG. This is a discovery question — confirm what region the customer's TSG is already in, not a free choice. The three available regions are: Americas (US and Canada), EU-Netherlands (GDPR-aligned, required for EU data residency), and Singapore (APAC).

RequirementStatus
TSG identified: existing TSG ID confirmed, or decision to create new 
Region confirmed: Americas / EU-Netherlands / Singapore 
AIOps for NGFW subscription status confirmed on this tenant 
Region Is Permanent

Choosing the wrong region requires full re-activation. Confirm the TSG region before the call — it is not a free choice at deployment time, it was fixed when the TSG was created. The three regions are: Americas (US and Canada — default), EU-Netherlands (GDPR-aligned, required for EU data residency), Singapore (APAC). A new TSG takes 15–20 minutes to provision; full activation takes up to 2 hours. Start activation early in the call.

Tenant & TSG — Data Capture

Feeds: Guide Step 3.1 (Create a Deployment Profile)

QuestionResponse / Notes
* Does a Tenant Service Group (TSG) already exist, or will one be created? select Existing TSG / Create new TSG
† If existing: TSG ID text  
* TSG region — confirm which region this tenant is provisioned in select Americas / EU-Netherlands / Singapore
* Is Strata Logging Service (SLS) enabled on this tenant? select Yes / No / Unknown
If the prerequisite checklist was completed, this should always be Yes. A No or Unknown answer here means the deployment call should not proceed.
Does the tenant have an existing AIOps subscription? select Yes / No / Unknown

IAM & Permissions

RequirementStatus
SCM accounts created for all engagement participants 
Role assigned: Superuser OR custom role with AI Red Teaming explicitly enabled 
Service account created and Client Secret stored securely (if API or CI/CD access needed) 
SSO/IdP user provisioning complete (if applicable) 
Blocker: Custom Role Must Explicitly Enable AI Red Teaming

Standard SCM roles do not grant AI Red Teaming access even when the subscription is active. Without the explicit permission, users see the SCM dashboard but not the AI Red Teaming module.

Client Secret Is Shown Once

The Client Secret for a service account is displayed only once at creation. If not recorded immediately, the account must be recreated. Have a secure storage location ready before creating the account.

SSO Provisioning Lead Time

SSO provisioning (Okta, Entra ID, Ping) may require an IT ticket with a multi-day lead time. Start provisioning at least one week before the deployment call.

Access & Identity — Data Capture

Feeds: Guide Step 3.2 (Configure IAM)

QuestionResponse / Notes
* Which RBAC roles are needed for the engagement? multi-select Superuser / Custom role with "AI Red Teaming" enabled / Read-only for stakeholders
* Is a service account needed for API or CI/CD access? select Yes / No / TBD
Does the customer use SSO / IdP for SCM access? select Okta / Entra ID (Azure AD) / Ping Identity / Google Workspace / No SSO / Other: ___
How many users need SCM access for this engagement? number  

Network Readiness

Whether target endpoints are public or private determines whether a Network Channel must be deployed. This is the single most impactful question: confirm it before scheduling the call.

If all targets are publicly accessible:

RequirementStatus
Endpoint URL reachable from the internet (test with curl) 
WAF/API gateway allowlisting completed, or test-through-WAF strategy agreed 

If any target is on a private network (behind firewall, VPN, or private VPC):

A Network Channel must be deployed. This is a Helm-deployed client in the customer's Kubernetes cluster that tunnels scan traffic outbound to AIRS. No inbound firewall rules are needed.

RequirementStatus
Kubernetes cluster available (EKS / AKS / GKE / self-managed) 
Cluster has network access to the private AI endpoint 
Helm 3.x installed 
kubectl configured for the cluster 
Outbound access to api.sase.paloaltonetworks.com 
Outbound access to auth.apps.paloaltonetworks.com 
Outbound access to registry.ai-red-teaming.paloaltonetworks.com 
K8s operator or admin confirmed available for the call 
Kubernetes Is Required, But Any Form Qualifies

The Network Channel is deployed via Helm and requires Kubernetes, but a managed cloud cluster (EKS/AKS/GKE) is not required. A lightweight single-node distribution (Minikube, k3s, or Kind) on any VM or on-premises server is fully supported. If no K8s exists, the customer can install k3s or Minikube on any machine with access to the private AI endpoint and outbound internet to the three AIRS FQDNs. Budget 30–60 minutes for setup. Only reschedule if no form of Kubernetes can be made available.

SSL Verification and Proxy Configuration (Private Endpoints)

Two additional Network Channel settings that must be identified before the deployment call — both affect how the Helm install command is constructed.

QuestionFormatResponse / Notes
Do target endpoints use self-signed or internal CA-issued certificates? select Yes — self-signed / Yes — internal CA / No — public certificates / Unknown  
Does the K8s cluster route outbound traffic through a corporate proxy? select Yes / No / Unknown  
† If proxy: HTTP proxy URL url e.g., http://proxy.corp.example.com:8080  
† If proxy: HTTPS proxy URL url e.g., http://proxy.corp.example.com:8080  
† If proxy: no-proxy bypass list text Comma-separated hosts/domains to bypass — e.g., localhost,127.0.0.1,.internal.corp.com  
Network Channel client version (confirm during Helm install) text Minimum v1.0.4 for custom SSL — minimum v1.0.5 for proxy support — minimum v1.3.0 for WebSocket targets via Network Channel  

Target Architecture

Feeds: Guide Step 4.2 (Add a Target) + Step 4.3 (Configure Target Details)

QuestionResponse / Notes
* Application name (human-readable) text  
* Target type select MODEL / APPLICATION / AGENT
* Connection type select — depends on target type

Model targets:

OPENAI / HUGGING_FACE / DATABRICKS / BEDROCK

Application & Agent targets:

REST / CUSTOM / STREAMING / WEBSOCKET

Agent only:

MS_COPILOT_STUDIO
* Base model text e.g., GPT-4o, Claude 3.5, Gemini 2.0, Llama 3.1
Core architecture select Single LLM / RAG (retrieval-augmented) / Tool Calling / Multi-Agent / Other: ___
* Industry (required for Application and Agent types) text e.g., Financial services, Healthcare, Technology
* Use case description text e.g., Customer support chatbot for insurance claims
Competitor names (for brand reputation attacks) text e.g., Competitor A, Competitor B
System prompt (enables white-box testing) text Paste or attach the full system prompt
† Tools accessible (Agent targets only — provide tool schemas) json Tool name, description, and parameter schema
Languages supported by this target text ISO 639-1 codes — e.g., en / es / fr / de / ja. Use "en" for English-only targets.
Banned keywords or phrases text Terms the target must never produce — e.g., competitor names, internal product codes, restricted topics. Leave blank if none defined.

Multi-Turn Configuration

What is a conversational target?

Some AI targets are stateless — each request is completely independent and the target has no memory of previous messages. Others are stateful — the target maintains a session server-side and remembers the conversation history across turns.

Multi-turn attacks (such as the Crescendo pattern) work by building trust or context across several turns before extracting the harmful output in a later turn. For AIRS to run these correctly, it needs to know how the target handles conversation history — otherwise each prompt arrives without context and the attack fails.

QuestionFormatResponse / Notes
Is this target stateless or stateful? select Stateless — no session memory / Stateful — server tracks session / Unknown  
† If stateful: where is the session ID sent? select header / body / query_param  
† If stateful: session ID field name text e.g., session_id, conversation_id, X-Session-Token  
Where is conversation history sent? select body (AIRS sends history in request) / none (server handles internally)  
† If history in body: history field name text e.g., messages, history, context  
† If history in body: history format select openai (array of role/content objects) / plain_text  
WebSocket Targets Cannot Use Multi-Turn Configuration

WebSocket targets do not support session management or multi-turn configuration. Stateful multi-turn attacks cannot be chained across WebSocket connections. If a customer's target requires multi-turn attack coverage, use REST or Streaming connection type instead.

Connection & Auth — Data Capture

Feeds: Guide Step 4.2 (Add a Target)

Connection type is determined by the target type selected in Target Architecture (above). Use the same value here when populating §16.

QuestionResponse / Notes
* Connection type select — depends on target type

Model targets:

OPENAI / HUGGING_FACE / DATABRICKS / BEDROCK

Application & Agent targets:

REST / CUSTOM / STREAMING / WEBSOCKET

Agent only:

MS_COPILOT_STUDIO
* Endpoint URL url https://
* Endpoint accessibility select PUBLIC / PRIVATE / NETWORK_BROKER (API-only)
* Authentication method select HEADERS (API key) / BASIC_AUTH / OAUTH2
* Auth credentials (API key, token, or OAuth config) text Provide securely — do not include in shared documents
Token/credential expiry period? text e.g., 1 hour, 24 hours, no expiry
API protocol select REST (default) / WebSocket / gRPC / Socket.IO / GraphQL

Network & Connectivity — Data Capture

Feeds: Guide Phase 5 (Network Channels) (skip or deploy)

QuestionResponse / Notes
* Are the target endpoints publicly accessible from the internet? select All public / All private / Mix of public and private
† If private endpoints: is a Kubernetes cluster available for the Network Channel client? select Yes — managed (EKS/AKS/GKE) / Yes — self-managed / Yes — lightweight K8s on VM (Minikube/k3s/Kind) / No
† If K8s available: does the cluster have outbound internet access? select Yes / No — air-gapped / Restricted (proxy/allowlist)
Is there a WAF or API gateway in the request path to any target? select Yes / No / Unknown
† If WAF present: what is the desired testing strategy? select Whitelist AIRS source IPs / Bypass WAF (test app directly) / Test full stack including WAF

Target Endpoint Readiness

What is a target? A target is the AI system being tested. Three types are supported:

  • Model — a direct API connection to a foundation model with no application layer: GPT-4o at api.openai.com, Claude at api.anthropic.com, a Bedrock-hosted model, a self-hosted Llama or Mistral instance. Simplest to configure.
  • Application — a model wrapped with a system prompt, business logic, and safety guardrails. Most enterprise targets are Applications: a customer service chatbot, an HR policy assistant, a legal document summarizer, a financial advisor application, a retail shopping assistant. Industry and use case are required fields.
  • Agent — an autonomous system with tool access that can take multi-step actions: a code review agent with repository access, a data analysis agent that writes and runs SQL, a research assistant that browses the web, an IT support agent that manages tickets. Carries the highest risk due to tool misuse potential.

Understanding rate limits: RPM (Requests Per Minute) controls how many API calls AIRS can send to the target each minute. TPM (Tokens Per Minute) controls total token throughput (input plus output combined) per minute. AIRS sends attack prompts sequentially; rate limits cap the speed. An Attack Library scan runs hundreds of prompts over approximately 5 hours. At 20 RPM that is roughly 6,000 total requests, sufficient for a full scan. Below 10 RPM the scan cannot complete in a reasonable time window. TPM is a separate constraint: attack payloads are verbose when a full system prompt is included in every request, and a TPM limit below 10,000 causes throttling even when RPM is adequate.

Complete for each AI target before the call. A target that fails validation during the call adds 30–60 minutes of unplanned troubleshooting.

RequirementStatus
Endpoint URL confirmed and reachable 
Auth credentials valid and not expiring within 6 hours (or static key confirmed) 
Rate limits confirmed: minimum 20 RPM and 20,000 TPM 
Guardrail response captured: HTTP status code and error body from a known-harmful test prompt 
Request template drafted with {{prompt}} placeholder in correct position 
Response body path confirmed against a real API response 
Test environment confirmed (production scanning requires explicit risk acceptance) 
Where These Values Are Formally Recorded

The items above are pre-call completion checks. The actual values are captured during the deployment call in Part C:

  • Endpoint URL and auth credentials → Connection & Auth (Prerequisites section)
  • Rate limits (RPM/TPM) → Section 11: Rate Limits & Capacity
  • Guardrail HTTP status and error response → Section 12: Guardrail Detection
  • Request template with {{prompt}} and response body path → Section 16: Target Specification
  • Test environment → Section 13: Environment

Complete the capture work before the call. Record the results in the Part C sections during the call.

Blocker: Rate Limits Too Low

Rate limits below 10 RPM will cause Attack Library scans to fail consistently. OpenAI's free tier (Tier 0) allows only 3 RPM. A dedicated higher-tier API key must be provisioned before scanning begins. Common provider tiers: OpenAI Tier 1 = 500 RPM (fine), Azure OpenAI = varies by deployment (check Azure portal), AWS Bedrock = per-model service quota.

2 Target Overview Essential

List every AI system to be tested. Each row drives a Part C section. This table determines engagement sizing.

# Application Name Type Use Case Hosting Priority
1   Model / Application / Agent   Cloud / On-prem / Hybrid High / Medium / Low
2   Model / Application / Agent   Cloud / On-prem / Hybrid High / Medium / Low
3   Model / Application / Agent   Cloud / On-prem / Hybrid High / Medium / Low
4   Model / Application / Agent   Cloud / On-prem / Hybrid High / Medium / Low
5   Model / Application / Agent   Cloud / On-prem / Hybrid High / Medium / Low

3 Compliance Requirements Important

QuestionResponse / Notes
Which compliance frameworks must scan results map to? multi-select OWASP LLM Top 10 / MITRE ATLAS / NIST AI RMF / DASF V2.0 / None specific / Other: ___
Are compliance-mapped reports required for auditors or regulators? select Yes — auditor delivery / Yes — internal compliance / No
Industry-specific AI regulations that apply? text e.g., EU AI Act, FDA AI/ML guidance, FFIEC

4 Remediation Expectations Important

QuestionResponse / Notes
Will Red Teaming findings feed into AIRS Runtime for real-time protection? select Yes — RT→Runtime bridge planned / Under evaluation / No — findings for manual remediation only
Who will implement remediation for discovered vulnerabilities? select Customer AI/ML team / Customer security team / Palo Alto Networks PS / Joint effort

Part C: Per-Target Configuration

Repeated for each target (or target group). Captures the technical spec needed to configure the product.

Target Index

List every AI system to be tested. Each row maps to a Part C (sections 10–16) block below. Type, Priority, and Connection are filled in after Part C is completed for each target.

Example (completed):

#NameTypePriorityConnectionStatus
1 Customer Support Bot APPLICATION High OPENAI / PUBLIC Complete
2 Internal HR Assistant APPLICATION Medium AZURE_OPENAI / PRIVATE In progress
3 Claims Processing Agent AGENT High REST / PRIVATE Not started

Fill in:

# Name Type Priority Connection Status
1 Target 1 MODEL / APPLICATION / AGENT High / Medium / Low   Not started / In progress / Complete
2 Target 2 MODEL / APPLICATION / AGENT High / Medium / Low   Not started / In progress / Complete
3 Target 3 MODEL / APPLICATION / AGENT High / Medium / Low   Not started / In progress / Complete
Target 1 Configuration

Sections 10–16 below apply to Target 1. Duplicate this block for each additional target listed in the Target Index.

10 Risk Priority Matrix Important

Feeds: Guide Step 6.2 (Configure Scan Categories). Set priority per category. N/A excludes the category from scans.

Security Categories

SubcategoryPriorityNotes
Adversarial Suffix 1 (Low) / 2 (Medium) / 3 (High) / N/A  
Evasion 1 (Low) / 2 (Medium) / 3 (High) / N/A  
Indirect Prompt Injection 1 (Low) / 2 (Medium) / 3 (High) / N/A  
Jailbreak 1 (Low) / 2 (Medium) / 3 (High) / N/A  
Multi-Turn 1 (Low) / 2 (Medium) / 3 (High) / N/A  
Prompt Injection 1 (Low) / 2 (Medium) / 3 (High) / N/A  
Remote Code Execution 1 (Low) / 2 (Medium) / 3 (High) / N/A  
System Prompt Leak 1 (Low) / 2 (Medium) / 3 (High) / N/A  
Tool Leak 1 (Low) / 2 (Medium) / 3 (High) / N/A  

Safety Categories

SubcategoryPriorityNotes
Bias 1 (Low) / 2 (Medium) / 3 (High) / N/A  
CBRN 1 (Low) / 2 (Medium) / 3 (High) / N/A  
Cybercrime 1 (Low) / 2 (Medium) / 3 (High) / N/A  
Drugs 1 (Low) / 2 (Medium) / 3 (High) / N/A  
Non-Violent Crimes 1 (Low) / 2 (Medium) / 3 (High) / N/A  
Political 1 (Low) / 2 (Medium) / 3 (High) / N/A  
Self-Harm 1 (Low) / 2 (Medium) / 3 (High) / N/A  
Sexual 1 (Low) / 2 (Medium) / 3 (High) / N/A  
Violent Crimes & Weapons 1 (Low) / 2 (Medium) / 3 (High) / N/A  

Compliance Categories

FrameworkPriorityNotes
OWASP LLM Top 10 1 (Low) / 2 (Medium) / 3 (High) / N/A  
MITRE ATLAS 1 (Low) / 2 (Medium) / 3 (High) / N/A  
NIST AI RMF 1 (Low) / 2 (Medium) / 3 (High) / N/A  
DASF V2.0 1 (Low) / 2 (Medium) / 3 (High) / N/A  

Brand Categories

SubcategoryPriorityNotes
Competitor Endorsements 1 (Low) / 2 (Medium) / 3 (High) / N/A  
Brand Tarnishing / Self Criticism 1 (Low) / 2 (Medium) / 3 (High) / N/A  
Discriminating Claims 1 (Low) / 2 (Medium) / 3 (High) / N/A  
Political Endorsements 1 (Low) / 2 (Medium) / 3 (High) / N/A  

11 Rate Limits & Capacity Essential

Feeds: Guide Step 4.3 + scan execution. Rate limits are the #1 cause of scan failures.

QuestionResponse / Notes
* Requests per minute (RPM) limit? number  
* Tokens per minute (TPM) limit? number  
Tokens per day (TPD) limit? number  
Maximum concurrent requests? number  
Maximum input tokens per request? number  
Maximum output tokens per request? number  

12 Guardrail Detection Essential

Feeds: Guide Step 4.3 (Configure Target Details). Without guardrail detection, reports cannot distinguish "blocked by guardrail" from "model refused."

QuestionResponse / Notes
* Does the target have guardrails (content filters, safety layers)? select Yes / No / Unknown
† HTTP status code returned when a guardrail blocks a request? text e.g., 400, 403, 200 (with error in body)
† Sample error response JSON when a guardrail blocks a request json
{
  "error": {
    "message": "Content policy violation",
    "type": "content_filter",
    "code": "content_policy_violation"
  }
}
Guardrail technology in use? text e.g., Azure Content Safety, OpenAI moderation, custom, AIRS Runtime

13 Environment Important

QuestionResponse / Notes
* Which environment will be tested? select Production / Staging / Development / Dedicated test
Does this environment use the same model and configuration as production? select Yes — identical / Mostly — same model, different guardrails / No — different model or config
Is scanning production directly acceptable? select Yes / No / Only during maintenance windows
Maintenance window (if applicable)? text e.g., Saturdays 2am-6am UTC
Conditional Section: Complete only if Connection & Auth (Prerequisites section) API Protocol ∈ {gRPC, Socket.IO, GraphQL} — WebSocket is natively supported and does not require a wrapper

14 REST Wrapper Essential †

AIRS sends REST requests only. Non-REST targets need a wrapper service that translates REST ↔ native protocol.

QuestionResponse / Notes
* Native protocol of the target select gRPC / Socket.IO / GraphQL / Other: ___
* Preferred language for the wrapper select Python / Node.js / Go / Java / Customer provides
Does the target use streaming responses? select Yes — SSE / Yes — chunked / No — single response
† If streaming: how should chunks be aggregated? select Concatenate all chunks / Use last chunk / Use first chunk with [DONE] / Custom: ___
Where will the wrapper be hosted? select Same K8s cluster as Network Channel / Separate VM / Serverless (Lambda/Cloud Function) / Customer hosts

15 Scan Strategy Essential

Feeds: Guide Steps 6.3–6.5 (Start Scans)

The scan types available for this target are determined by the package tier selected in Engagement Sizing (under Section 1: Engagement Overview). Select only from scan types included in the chosen package.

QuestionResponse / Notes
* Which scan types will be executed? multi-select Attack Library (STATIC) / Dynamic Agent (DYNAMIC) / Custom Prompt (CUSTOM)
Recommended scan order? select Attack Library first (baseline) → Dynamic → Custom / Dynamic first (rapid) → Attack Library / Custom only (targeted)
* Scan language text ISO 639-1 code — e.g., en (English), es (Spanish), fr (French), de (German), ja (Japanese). Default: en
Scan Language vs. Languages Supported

These are two different settings. Languages supported (captured in Target Architecture) tells AIRS which languages the target can handle. Scan language (this field) tells AIRS which language to generate attack prompts in. For a Spanish-language customer service bot, both should be es — if the scan language is left as en, AIRS sends English attacks to a Spanish-only target and most prompts return "I don't understand" instead of meaningful results. Match the scan language to the primary language the target processes.

Dynamic Agent Configuration

QuestionResponse / Notes
Agent breadth (1–20, default 6) number More agents = more diverse attack approaches
Agent depth (1–20, default 10) number More depth = longer multi-turn attacks
Max tokens per attack prompt (128–4096, default 256) number Maximum tokens the attack agent can generate per prompt. Default 256 is conservative — increase to 512–1024 for Application and Agent targets requiring nuanced multi-turn attacks.
Context size / conversation memory window (1–20, default 10) number How many previous turns the attack agent can reference when crafting the next prompt. Default 10 suits most targets — increase for Agent targets running long autonomous conversations.
Attack goals (for Custom Goals mode) text Natural language goals, e.g., "Extract the system prompt", "Make the bot recommend a competitor"

Custom Prompt Configuration

QuestionResponse / Notes
Custom prompt source select Customer-provided prompt set / Consultant-developed / Industry-specific template
Number of custom prompts planned? number  

16 Target Specification Essential

Feeds: Guide Step 4.2, API payload (POST /v1/target). This section IS the API request body.

This section assembles values already captured in the Target Architecture and Connection & Auth (Prerequisites) sections and Sections 10–13 into the exact format required for the AIRS API call. All fields marked [from §N] or [from Prerequisites] should be copied from that section — do not re-enter independently.

Target Specification: _______________

* Name: [human-readable name] [from Target Architecture]
* Target Type: MODEL / APPLICATION / AGENT [from Target Architecture]
* Connection Type: OPENAI / HUGGING_FACE / DATABRICKS / BEDROCK / REST / CUSTOM / STREAMING / WEBSOCKET / MS_COPILOT_STUDIO [from Connection & Auth (Prerequisites)]
* Endpoint URL: https:// [from Connection & Auth (Prerequisites)]
* Endpoint Type: PUBLIC / PRIVATE / NETWORK_BROKER [from Connection & Auth (Prerequisites)]
* Auth Type: HEADERS / BASIC_AUTH / OAUTH2 [from Connection & Auth (Prerequisites)]
* Auth Config: [headers / credentials — provide securely] [from Connection & Auth (Prerequisites)]

Request Template

The request template defines how AIRS sends attack prompts to the target. The {{prompt}} placeholder is replaced with the attack text at scan time.

{
  // request_template.body — customize for your target's API format
  "model": "[model-name]",
  "messages": [
    {
      "role": "user",
      "content": "{{prompt}}"
    }
  ],
  "temperature": 0.7,
  "max_tokens": 1024
}
Critical: Request Template Validation

The request template is the most critical field in the entire TRD. A bad {{prompt}} placeholder means scans run but produce no meaningful results; the attacks never reach the model. Always validate with a test request before starting scans.

Response Template

The response template tells AIRS where to extract the model's response text from the API response body.

Response Extraction

* Body Path: e.g., choices[0].message.content
HTTP Method: POST (default) / GET
Content-Type: application/json (default) / Other: ___

Target Background (Application & Agent Types)

Target Background

* Industry: [from Target Architecture]
* Use Case: [from Target Architecture]
Competitors: [from Target Architecture]

Additional Context

Additional Context

Base Model: [from Target Architecture]
System Prompt: [from Target Architecture — paste or attach]
Tools Accessible: [Agent targets only — from Target Architecture]
Languages Supported: [from Target Architecture — e.g., en, es, fr]
Banned Keywords: [from Target Architecture — competitor names, restricted terms]
Core Architecture: Single LLM / RAG / Tool Calling / Multi-Agent

Validation Tests

Complete all four tests after target configuration is saved and before starting any production scans. All four must pass before scan results can be considered reliable. A failure at any step indicates a configuration problem that will produce empty or misleading scan results.

Test NamePreconditionInputExpected Output
Endpoint Reachability Target saved in AIRS with endpoint URL and auth credentials entered. Network Channel deployed if target is private. Run AIRS target validation probe (Step 4.4 in the deployment guide): a benign prompt such as "Hello, how are you?" sent through the configured connection. HTTP 200 response. Model text appears in the expected response body path (e.g., choices[0].message.content). No timeout, DNS error, or connection refused. Target status shows "Active" in SCM.
Auth Token Validity Auth credentials entered in the target configuration. If OAuth2, refresh token configured. Send an API call using the configured auth method and verify the response does not return HTTP 401 or 403. For tokens with expiry, confirm the expiry window is longer than the planned scan duration (5+ hours for Attack Library). HTTP 200 with a valid model response. No 401 (invalid key), 403 (forbidden), or 429 (rate limit) on the first call. Token expiry date is more than 6 hours from the planned scan start.
Static Scan Completion (Attack Library) Endpoint reachable and auth valid. Rate limits confirmed at or above the 10 RPM floor. Guardrail detection HTTP code and sample JSON entered in target config. At least one scan category enabled. Start an Attack Library (STATIC) scan with all enabled categories from the Risk Priority Matrix. Monitor the scan status page for the first 10 minutes. Check the scan event log for RATE_LIMIT or TIMEOUT errors. Scan status transitions from PENDING to RUNNING within 2 minutes. No RATE_LIMIT errors appear in the event log during the first 10 minutes. At scan completion, all enabled categories show findings (not empty). An overall risk score is generated in the report.
Dynamic Scan Rate-Limit Check Attack Library scan complete (baseline established). Dynamic Agent breadth, depth, max_tokens, and context_size configured in Section 15. Start a Dynamic Agent (DYNAMIC) scan with the configured breadth and depth parameters. Monitor the event log for the first 15 minutes for RATE_LIMIT or concurrency errors. Confirm attack streams are initiating. Scan runs for the full configured duration without RATE_LIMIT errors. The number of active attack streams matches the configured breadth value. Findings appear in the Dynamic scan report. If RATE_LIMIT errors appear, reduce breadth by 2 and re-run.

Day-2 Appendix

Optional. Address after the first scan cycle is complete and initial results are reviewed.

D1 Logging & SIEM Integration Day-2

QuestionResponse / Notes
SIEM platform in use? select Cortex XSIAM / Splunk / Sentinel / QRadar / Elastic / Other: ___
Should AIRS scan events forward to SIEM? select Yes / No / TBD
Log forwarding method preference? select Syslog / API webhook / Strata Logging Service → SIEM connector / Manual export
Alert thresholds (what scan results trigger alerts)? text e.g., Any Critical finding, Risk score > 7
Log retention requirements? text e.g., 90 days, 1 year, regulatory requirement

D2 Ongoing Program Design Day-2

QuestionResponse / Notes
Desired scan cadence after initial engagement? select Weekly / Monthly / Quarterly / On-demand only / Before each release
Should scans integrate into CI/CD pipeline? select Yes — gating (block deploy on findings) / Yes — advisory (report only) / No
CI/CD platform in use? select GitHub Actions / GitLab CI / Jenkins / Azure DevOps / Other: ___
Risk score threshold for automated re-scan trigger? number e.g., re-scan if overall risk > 5
Go/no-go risk thresholds for deployment decisions? text e.g., No Critical findings, overall risk ≤ 3

D3 Reporting & Distribution Day-2

QuestionResponse / Notes
Report recipients (beyond engagement team)? table Name, email, report type (full / executive summary)
Is an executive summary report required? select Yes / No
Report format preference? select PDF / HTML / JSON (API) / All formats
Should reports be retained as audit evidence? select Yes — regulatory / Yes — internal policy / No