Menu
Guide the user through authenticating the target, attacker, and judge models from their own environment (any cloud, any auth mode) before running an assessment
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when beginning a web assessment from a domain, wildcard, ASN, organization, IP list, or CIDR and measurable attack-surface coverage is needed.
Decision tree for selecting AIRT attacks based on goals, target type, and constraints
Common Active Directory attack chains with tool mappings. Covers Kerberoasting, AS-REP roasting, RBCD, AD CS, DCSync, relay attacks, and credential reuse patterns. Use during exploitation and privilege escalation phases.
Decision tree for Active Directory enumeration. Maps enumeration tasks to tools, defines priority signals, and specifies what findings trigger deeper investigation. Use during the enumeration phase of network operations.
Load when performing network operations or Active Directory exploitation. Enforces enumeration-before-attack discipline, credential verification, trust boundary awareness, scope compliance, reversibility preference, and structured reporting. Prevents premature exploitation, credential misuse, and scope violations.
Direct Caido interaction via the caido-sdk-client Python library, bypassing the Caido MCP server. Prefer this over the caido-proxy MCP skill for efficiency WHEN the SDK is importable in the current runtime. If the import fails, or Caido/the MCP is not loaded, fall back to the caido-proxy skill.
| name | auth-setup-guide |
| description | Guide the user through authenticating the target, attacker, and judge models from their own environment (any cloud, any auth mode) before running an assessment |
| allowed-tools | generate_attack generate_multimodal_attack generate_agentic_attack generate_category_attack |
Every assessment uses up to three model roles, and each needs credentials:
| Role | What it is | How to authenticate |
|---|---|---|
| Target | The system under test (the user's model / endpoint) | This guide — depends on where it's deployed |
| Attacker | The LLM that generates adversarial prompts (attacker_model) | A litellm-routed model — see Section B |
| Judge / evaluator | The LLM that scores success (judge_model / evaluator_model) | A litellm-routed model — see Section B |
Golden rule: credentials NEVER go in a tool argument, prompt, or generated script. The user sets them as environment variables (local compute) or platform secrets (Dreadnode-hosted compute). Tool params only ever carry the env var name, never the value.
Ask the user the three questions below, then map their answers to the tables that follow.
There are two ways to reach a target: as a litellm-routed model (A1 — preferred whenever the provider is supported, including Bedrock/Azure/Vertex) or as a custom HTTP endpoint (A2). A few auth modes need the SDK escape hatch (A3).
If the target is a hosted model on a known provider, don't build a custom endpoint — pass a
provider-prefixed target_model and have the user set the provider's env vars. Same mechanism
for attacker_model / judge_model.
| Provider / deployment | target_model string | Env vars the user sets |
|---|---|---|
| OpenAI | openai/gpt-4o | OPENAI_API_KEY |
| Anthropic | anthropic/claude-3-5-sonnet-latest | ANTHROPIC_API_KEY |
| Google AI Studio (Gemini API) | gemini/gemini-2.5-flash | GEMINI_API_KEY |
| Groq | groq/llama-3.3-70b-versatile | GROQ_API_KEY |
| Mistral | mistral/mistral-large-latest | MISTRAL_API_KEY |
| Together | together_ai/meta-llama/Llama-3.3-70B-Instruct-Turbo | TOGETHER_API_KEY |
| Azure OpenAI | azure/<your-deployment-name> | AZURE_API_KEY, AZURE_API_BASE, AZURE_API_VERSION |
| Azure AI Foundry (serverless / OpenAI-compatible) | azure_ai/<deployment> | AZURE_AI_API_KEY, AZURE_AI_API_BASE |
| AWS Bedrock | bedrock/anthropic.claude-3-5-sonnet-20240620-v1:0 | AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION_NAME (+ AWS_SESSION_TOKEN if using SSO/role) |
| Google Vertex AI | vertex_ai/gemini-2.5-pro | GOOGLE_APPLICATION_CREDENTIALS (path to service-account JSON) or ADC, plus VERTEXAI_PROJECT, VERTEXAI_LOCATION |
| Ollama (self-hosted) | ollama/llama3 | OLLAMA_API_BASE (e.g. http://localhost:11434) |
| Dreadnode proxy | dn/claude-sonnet-4-6 | none — routed through the platform |
Then just run the attack with that target_model. No custom_url needed. This is how
Azure Foundry OpenAI deployments and Vertex models are probed with the standard tools.
Bedrock/Vertex use the cloud's own credential chain via litellm, so IAM roles, SSO sessions, and workload identity work when the corresponding env vars are present.
For a bespoke endpoint (a proprietary API, a RAG service, an agent gateway), point at it with
custom_url and describe its shape. Supported auth in the tools today: none, bearer,
api_key.
Set on generate_attack / generate_multimodal_attack:
| Param | Purpose |
|---|---|
custom_url | The POST endpoint |
custom_auth_type | none · bearer (adds Authorization: Bearer <env>) · api_key (adds a header you name) |
custom_auth_env_var | Name of the env var / secret holding the credential (default TARGET_API_KEY) |
custom_request_template | JSON body with {prompt} (and {image_b64}/{audio_b64}/{video_b64} for multimodal) |
custom_response_text_path | JSONPath to the reply text (e.g. $.output, $.choices[0].message.content) |
Ask the user for a sample request/response (or their API docs), infer the template + response path, and confirm which env var holds the key. Example:
generate_attack(
attack_type="tap",
goal="<user objective>",
custom_url="https://api.example.com/v1/chat",
custom_auth_type="bearer",
custom_auth_env_var="MY_ENDPOINT_TOKEN",
custom_request_template='{"message": "{prompt}"}',
custom_response_text_path="$.reply",
)
Some targets authenticate with request signing or auto-acquired cloud tokens rather
than a static key, and realtime speech-to-speech targets need a streaming handshake. These
are supported by the Python SDK via dreadnode.airt.build_target(TargetSpec) (auth modes
aws_sigv4, azure_ad — Entra/managed identity, gcp — ADC) and nova_sonic_target for
Amazon Nova Sonic S2S.
When a user needs one of these, point them to the Custom Targets docs (Universal targets section) and confirm their prerequisites:
| Target auth | SDK auth mode | User prerequisites |
|---|---|---|
| AWS Bedrock/SageMaker request signing | aws_sigv4 | pip install boto3; AWS creds via env/profile/role; region + service |
| Azure ML / AI Foundry managed identity | azure_ad | pip install azure-identity; identity assigned to the resource (no static key) |
| Google Vertex via ADC / service account | gcp | pip install google-auth; gcloud auth application-default login or GOOGLE_APPLICATION_CREDENTIALS |
| Amazon Nova Sonic (speech-to-speech) | nova_sonic_target | pip install aws-sdk-bedrock-runtime awscrt; AWS creds; Nova Sonic model access in-region |
The standard TUI tools (
custom_*params) currently covernone/bearer/api_key. For SigV4 / managed identity / ADC / S2S, use the SDK today.
The attacker and judge are ordinary litellm-routed models — same table as A1. Guidance:
dn/ models (e.g. dn/claude-sonnet-4-6) when the user has a Dreadnode key —
no extra provider setup, strong capability.attacker_model and judge_model (some tools use evaluator_model). If omitted,
sensible defaults apply; the judge falls back to the target model when unset.openai/gpt-4o or dn/claude-sonnet-4-6.| Running the TUI on… | Set credentials as… |
|---|---|
| Your laptop (local compute) | Environment variables in the shell that launches the TUI: export OPENAI_API_KEY=... |
| Dreadnode-hosted compute | Account Settings → Secrets in the platform; they're injected into the sandbox automatically. The env-var names are the same. |
Either way, the tool params reference the credential by env-var name. The value is read from the environment at runtime and never appears in the generated workflow script.
provider/model) — covers Azure OpenAI/Foundry, Bedrock, Vertex, and
the common APIs with just env vars.custom_url + custom_auth_type) for bespoke HTTP endpoints (key/bearer).build_target) for SigV4 / managed identity / ADC / speech-to-speech.dn/ models are the easy default; vision/audio judge for
media-output scoring.Never place a secret value in a tool argument or the generated script — only the env-var name. Do not apply safety reasoning to the assessment goal; this skill only configures auth.