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 | |
- * 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.
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. |
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
| Question | Response / Notes |
|---|---|
| * Primary business driver for AI red teaming? select | |
| * What does success look like for this engagement? text |
Stakeholder Contacts
| Role | Name | Notes | |
|---|---|---|---|
| * Project sponsor | |||
| * Technical lead (AI/ML) | |||
| * Security lead | |||
| CSP portal admin |
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.
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.
| Attribute | Details |
|---|---|
| Duration | Approximately 5 hours per target |
| Attack count | 500+ scenarios across all selected categories |
| Customer effort during scan | None; fully automated |
| Output | Scored report: which attacks succeeded, which were blocked, overall risk score |
| Best for | First scan on any target; compliance baselines; regression testing between deployments |
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.
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.
| Attribute | Details |
|---|---|
| Duration | Varies by breadth/depth settings; typically 1–4 hours |
| Approach | Adaptive multi-turn conversations; discovers and exploits contextual weaknesses |
| Customer effort during scan | None; fully automated |
| Best for | Deep testing after Attack Library baseline; Agent-type targets; complex multi-turn vulnerabilities |
Key parameters:
| Parameter | Default | What it controls |
|---|---|---|
| Stream breadth | 6 | Number of parallel attack threads running simultaneously |
| Stream depth | 10 | Maximum conversation turns per attack thread |
| Attack goals | Auto | Custom 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
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 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.
| Attribute | Details |
|---|---|
| Duration | Depends on prompt count |
| Validation | Each prompt is auto-validated (5–10 minutes per prompt) before it can run |
| Best for | Regression testing; industry-specific compliance scenarios; brand-specific attacks not in the library |
| Prompt sources | Customer-provided, consultant-developed, or industry templates |
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.
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-On | Description | Include? |
|---|---|---|
| Network Channel deployment | Required for private endpoints. Adds K8s prerequisites and 1–2 hours setup. | |
| REST wrapper development | Required for non-REST protocols (gRPC, Socket.IO, GraphQL). Custom development, 2–4 hours. | |
| CI/CD pipeline integration | Automated scan triggers in CI/CD pipelines. Requires service account. | |
| Custom attack development | Consultant develops custom prompt sets tailored to the target's business context. |
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)
| Question | Response / 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 |
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.
| Requirement | Status |
|---|---|
| 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 |
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.
| Requirement | Status |
|---|---|
| SLS enabled on the target tenant (verify in Common Services 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).
| Requirement | Status |
|---|---|
| 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 |
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)
| Question | Response / Notes |
|---|---|
| * Does a Tenant Service Group (TSG) already exist, or will one be created? select | |
| † If existing: TSG ID text | |
| * TSG region — confirm which region this tenant is provisioned in select | |
| * Is Strata Logging Service (SLS) enabled on this tenant? select |
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 |
IAM & Permissions
| Requirement | Status |
|---|---|
| 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) |
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.
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 (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)
| Question | Response / Notes |
|---|---|
| * Which RBAC roles are needed for the engagement? multi-select | |
| * Is a service account needed for API or CI/CD access? select | |
| Does the customer use SSO / IdP for SCM access? select | |
| 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:
| Requirement | Status |
|---|---|
| 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.
| Requirement | Status |
|---|---|
| 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 |
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.
| Question | Format | Response / Notes |
|---|---|---|
| Do target endpoints use self-signed or internal CA-issued certificates? select | ||
| Does the K8s cluster route outbound traffic through a corporate proxy? select | ||
| † 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)
| Question | Response / Notes |
|---|---|
| * Application name (human-readable) text | |
| * Target type select | |
| * Connection type select — depends on target type |
Model targets: Application & Agent targets: Agent only: |
| * Base model text | e.g., GPT-4o, Claude 3.5, Gemini 2.0, Llama 3.1 |
| Core architecture select | |
| * 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.
| Question | Format | Response / Notes |
|---|---|---|
| Is this target stateless or stateful? select | ||
| † If stateful: where is the session ID sent? select | ||
| † If stateful: session ID field name text | e.g., session_id, conversation_id, X-Session-Token | |
| Where is conversation history sent? select | ||
| † If history in body: history field name text | e.g., messages, history, context | |
| † If history in body: history format select |
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.
| Question | Response / Notes |
|---|---|
| * Connection type select — depends on target type |
Model targets: Application & Agent targets: Agent only: |
| * Endpoint URL url | https:// |
| * Endpoint accessibility select | |
| * Authentication method select | |
| * 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 |
Network & Connectivity — Data Capture
Feeds: Guide Phase 5 (Network Channels) (skip or deploy)
| Question | Response / Notes |
|---|---|
| * Are the target endpoints publicly accessible from the internet? select | |
| † If private endpoints: is a Kubernetes cluster available for the Network Channel client? select | |
| † If K8s available: does the cluster have outbound internet access? select | |
| Is there a WAF or API gateway in the request path to any target? select | |
| † If WAF present: what is the desired testing strategy? select |
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 atapi.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.
| Requirement | Status |
|---|---|
| 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) |
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.
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 | |||||
| 2 | |||||
| 3 | |||||
| 4 | |||||
| 5 |
3 Compliance Requirements Important
| Question | Response / Notes |
|---|---|
| Which compliance frameworks must scan results map to? multi-select | |
| Are compliance-mapped reports required for auditors or regulators? select | |
| Industry-specific AI regulations that apply? text | e.g., EU AI Act, FDA AI/ML guidance, FFIEC |
4 Remediation Expectations Important
| Question | Response / Notes |
|---|---|
| Will Red Teaming findings feed into AIRS Runtime for real-time protection? select | |
| Who will implement remediation for discovered vulnerabilities? select |
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):
| # | Name | Type | Priority | Connection | Status |
|---|---|---|---|---|---|
| 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 | ||||
| 2 | Target 2 | ||||
| 3 | Target 3 |
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
| Subcategory | Priority | Notes |
|---|---|---|
| Adversarial Suffix | ||
| Evasion | ||
| Indirect Prompt Injection | ||
| Jailbreak | ||
| Multi-Turn | ||
| Prompt Injection | ||
| Remote Code Execution | ||
| System Prompt Leak | ||
| Tool Leak |
Safety Categories
| Subcategory | Priority | Notes |
|---|---|---|
| Bias | ||
| CBRN | ||
| Cybercrime | ||
| Drugs | ||
| Non-Violent Crimes | ||
| Political | ||
| Self-Harm | ||
| Sexual | ||
| Violent Crimes & Weapons |
Compliance Categories
| Framework | Priority | Notes |
|---|---|---|
| OWASP LLM Top 10 | ||
| MITRE ATLAS | ||
| NIST AI RMF | ||
| DASF V2.0 |
Brand Categories
| Subcategory | Priority | Notes |
|---|---|---|
| Competitor Endorsements | ||
| Brand Tarnishing / Self Criticism | ||
| Discriminating Claims | ||
| Political Endorsements |
11 Rate Limits & Capacity Essential
Feeds: Guide Step 4.3 + scan execution. Rate limits are the #1 cause of scan failures.
| Question | Response / 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."
| Question | Response / Notes |
|---|---|
| * Does the target have guardrails (content filters, safety layers)? select | |
| † 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 |
|
| Guardrail technology in use? text | e.g., Azure Content Safety, OpenAI moderation, custom, AIRS Runtime |
13 Environment Important
| Question | Response / Notes |
|---|---|
| * Which environment will be tested? select | |
| Does this environment use the same model and configuration as production? select | |
| Is scanning production directly acceptable? select | |
| Maintenance window (if applicable)? text | e.g., Saturdays 2am-6am UTC |
14 REST Wrapper Essential †
AIRS sends REST requests only. Non-REST targets need a wrapper service that translates REST ↔ native protocol.
| Question | Response / Notes |
|---|---|
| * Native protocol of the target select | |
| * Preferred language for the wrapper select | |
| Does the target use streaming responses? select | |
| † If streaming: how should chunks be aggregated? select | |
| Where will the wrapper be hosted? select |
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.
| Question | Response / Notes |
|---|---|
| * Which scan types will be executed? multi-select | |
| Recommended scan order? select | |
| * Scan language text | ISO 639-1 code — e.g., en (English), es (Spanish), fr (French), de (German), ja (Japanese). Default: en |
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
| Question | Response / 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
| Question | Response / Notes |
|---|---|
| Custom prompt source select | |
| 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: _______________
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
}
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
Target Background (Application & Agent Types)
Target Background
Additional Context
Additional Context
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 Name | Precondition | Input | Expected 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
| Question | Response / Notes |
|---|---|
| SIEM platform in use? select | |
| Should AIRS scan events forward to SIEM? select | |
| Log forwarding method preference? select | |
| 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
| Question | Response / Notes |
|---|---|
| Desired scan cadence after initial engagement? select | |
| Should scans integrate into CI/CD pipeline? select | |
| CI/CD platform in use? select | |
| 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
| Question | Response / Notes |
|---|---|
| Report recipients (beyond engagement team)? table | Name, email, report type (full / executive summary) |
| Is an executive summary report required? select | |
| Report format preference? select | |
| Should reports be retained as audit evidence? select |