红队框架

Create an amd64 builder (required on Apple Silicon / ARM machines)

docker buildx create --name amd64builder --platform linux/amd64 --use

5. Custom Attack Categories (requires TypeScript)

For developers — implement the AttackModule interface in attacks/, ~30 lines:

import type { Attack, AttackModule } from "../lib/types.js";
const category = "my_custom_check" as const;
export const myCustomModule: AttackModule = {
  category,
  getSeedAttacks() { return [{ id: "mc-1", category, name: "...", ... }]; },
  getGenerationPrompt(analysis) { return "You are a red-team attacker..."; },
};

See CONTRIBUTING.md for the full guide.

---

1. Clone and install

git clone https://github.com/sundi133/wb-red-team.git cd wb-red-team && npm install

Option D: Docker Dashboard

```bash cp .env.example .env

If your target is on localhost (Docker needs host.docker.internal)

curl -X POST http://localhost:4200/api/run \ -H "Content-Type: application/json" \ -d "$(cat configs/config.my-app.json | sed 's/localhost:4000/host.docker.internal:4000/g')"

Docker

OpenShift Deployment

Prerequisites: OpenShift CLI (oc), Docker Hub account, access to an OpenShift cluster.

1. Build and push the amd64 image:

```bash

Build and push to Docker Hub

docker buildx build --builder amd64builder --platform linux/amd64 \ --no-cache --pull -t <your-dockerhub-user>/wb-red-team:latest --push .

**2. Configure secrets:**

Edit `deploy/openshift.yaml` and update the `wb-red-team-secrets` Secret with your API keys, auth credentials, and session secret. Alternatively, create the secret from your `.env` file:

**3. Update the namespace:**

The YAML defaults to `sundi133-dev`. If your namespace is different, update all `namespace:` fields in `deploy/openshift.yaml`.

**4. Deploy:**

**5. Verify:**

Rebuild and push

docker buildx build --builder amd64builder --platform linux/amd64 \ --no-cache --pull -t <your-dockerhub-user>/wb-red-team:latest --push .

Restart the deployment to pull the new image

oc rollout restart deployment/wb-red-team

**Troubleshooting:**

- `exec format error` — Image was built for ARM, not amd64. Rebuild with `--platform linux/amd64 --pull --no-cache`.
- `ImagePullBackOff` — Docker Hub repo is private. Either make it public or create a pull secret:
  

---

Enterprise Deployment

Deploy anywhere — AWS, GCP, Azure, Railway, on-prem, or any environment that runs Docker + Postgres.

Prerequisites: Docker runtime, Postgres 13+, OIDC identity provider (Clerk, Okta, Azure AD, Auth0, Keycloak)

Features:

• Postgres storage with AES-256-GCM envelope encryption for reports at rest
• SSO authentication via any OIDC provider
• API key authentication (X-API-Key header) for CI/CD
• RBAC: admin (full), viewer (read reports), auditor (compliance + audit log)
• Multi-tenant isolation — every query scoped by tenant_id
• Immutable audit log
• Dev mode (AUTH_MODE=dev) for frictionless local testing

Environment Variables:

Quick Start

Quick Start (Local Dev)

```bash cp .env.example .env

Option A: Interactive Config Generator (recommended for first-time users)

```bash

Edit .env — add at least one LLM key: ANTHROPIC_API_KEY, OPENAI_API_KEY, TOGETHER_API_KEY, AZURE_OPENAI_API_KEY, or CUSTOM_LLM_BASE_URL

3. Generate config interactively

npm run gen:interactive ```

The interactive generator walks you through app details, authentication, smart category selection with reasoning, strategy selection, intensity, and LLM provider. Iterate until satisfied, then save and run.

Option B: CLI with config file

```bash cp config.example.json config.json

Edit config.json: set baseUrl, agentEndpoint, codebasePath

npm start ```

Option C: AI Assistant (natural language)

```bash npm run ai

Edit .env with your LLM API key

docker compose up -d

Trigger a run via API (after config is created)

```bash

Using a config file

curl -X POST http://localhost:4200/api/run \ -H "Content-Type: application/json" \ -d @configs/config.my-app.json

Add your LLM API key + optionally:

.env

DATABASE_URL=postgres://user:pass@host:5432/redteam MASTER_ENCRYPTION_KEY=<openssl rand -hex 32> CLERK_PUBLISHABLE_KEY=pk_live_...

.env

CUSTOM_LLM_BASE_URL=https://your-internal-gateway.com/provider/generic CUSTOM_LLM_API_KEY=your-key

If your OpenAI-compatible gateway supports request-level guardrails, you can attach them only when needed:

When configured, outbound OpenAI-style requests are sent in this shape:

**API keys for programmatic access:**

With API key (enterprise mode)

curl -X POST http://localhost:4200/api/run \ -H "X-API-Key: rtk_your_api_key" \ -H "Content-Type: application/json" \ -d @configs/config.insurance.json ```

---

Integrations

Copy-paste configs for the agent frameworks people actually use:

• LangChain / LangServe
• LlamaIndex (RAG)
• Vercel AI SDK (Next.js)
• OpenAI Agents SDK
• CrewAI
• MCP servers
• Next.js app router (generic)
• RAG apps (framework-agnostic)
• Slack / Discord / email agents

See the full integrations index for the shared pattern (only three config fields define an integration).

---

Red-Team AI vs black-box scanners

---

Red-Team AI vs Promptfoo — deep comparison

Both are MIT-licensed, TypeScript-based. Promptfoo has 20k+ stars, OpenAI backing, and is the most mature LLM red-team tool. Red-Team AI is early-stage but fills a structural gap: white-box testing.

Where Red-Team AI is stronger:

Where Promptfoo is stronger:

Use both — they're complementary:

• Promptfoo for black-box testing of endpoints you don't own, model eval, CI/CD PR scanning, and dataset benchmarks
• Red-Team AI for white-box testing where you own the source, agentic apps with tools/roles, and self-hosted enterprise deployment with compliance

Promptfoo is DAST for AI. Red-Team AI is SAST+DAST for AI. Application security has always needed both.

---