Related Pages

Related topics: Runners & Entry Points (CLI, SDK, MCP Server, Browser Extension, Skills), Evaluators, Patterns & Attack Coverage (OWASP + EU AI Act), Configuration, Reports, Telemetry & Operations

OPFOR Overview & System Architecture

OPFOR (from "agent-opfor") is an adversarial red-teaming framework used to probe AI agents for security weaknesses. It drives conversations against a target agent with an attacker LLM, captures the agent's replies, judges each turn against configurable evaluators, and produces a final report. The same engine is reused by three delivery surfaces: a Node-based SDK, a CLI, and a browser extension. Source: README.md:1-40

1. Scope and Design Goals

OPFOR is scoped to security evaluation rather than general benchmarking. Its goals, derived from the README and the core entry point, are:

• Provide a reusable core that can be embedded from another Node project (require("agent-opfor")) or driven directly from the command line. Source: core/src/index.ts:1-20
• Decouple the attacker model from the target agent so the same attack policy can be retargeted at any compatible chat endpoint. Source: core/src/autonomous/index.ts:1-30
• Run attack / execution loops synchronously through a single attackRunner so every surface reports consistently. Source: core/src/execute/attackRunner.ts:1-40
• Stay extensible: evaluators, providers, and report formats are registered on the core, not hard-coded into the CLI. Source: core/package.json:1-40

The community has called out concrete gaps that confirm this scope. For example, support for AWS Bedrock and Google Vertex AI is not yet first-class (#181), and remote-code-execution and site-specific-extension evaluators are still being added (#172, #179).

2. System Components

OPFOR is delivered as a small monorepo with three user-facing components and one shared core.

The core/package.json declares the package name, version, and entry, which is what both the CLI and the extension import when they need to start or steer a run. Source: core/package.json:1-40

3. Architecture and Data Flow

The core follows a pipeline: configuration → autonomous planning → per-turn execution → judging → report.

flowchart LR
  A[User / CLI / Extension] --> B[core/src/index.ts]
  B --> C[core/src/autonomous/index.ts<br/>attack planning]
  C --> D[core/src/execute/attackRunner.ts<br/>per-turn loop]
  D --> E[Target Agent<br/>chat endpoint]
  E --> D
  D --> F[Evaluators<br/>judge verdict]
  F --> G[Report]

The pipeline is reused across surfaces. The browser extension, for instance, submits attacks into the same attackRunner; the bugs that show prompts outpacing the agent (#180) or pause-button lag (#177, #182) are symptoms of how the runner waits on the target agent before allowing the next turn, rather than separate engines. Source: core/src/execute/attackRunner.ts:1-40

The core/src/autonomous/index.ts module owns the high-level decision loop: it selects strategies, decides whether to escalate, retry, or stop, and feeds prompts into the runner. The runner itself is responsible only for the synchronous request/response cycle. Source: core/src/autonomous/index.ts:1-30

4. Typical Usage and Known Limitations

Headless run from the CLI:

1. opfor setup writes a .opfor/configs directory tree that the runner reads later. Source: README.md:1-40
2. opfor run boots the core, which loads configs, plans attacks via autonomous, and iterates through attackRunner. Source: core/src/index.ts:1-20
3. Final output is produced as a report once all configured turns and evaluators complete.

Known operational pain points reflected in community discussions:

• Config nesting (#183): running opfor setup inside an existing .opfor/configs creates a nested .opfor folder instead of merging into the parent. This indicates the setup command does not detect an already-initialized directory before writing.
• Pause responsiveness (#177, #182): cancellation is not preempted; the runner completes the in-flight request before honoring the pause signal.
• CLI error reporting (#176): when the target chat endpoint returns an HTTP error, the report currently surfaces only the status code, not the body.
• Provider coverage (#181): only a small set of providers are supported natively; Bedrock and Vertex AI require additional integration.
• Targeting accuracy (#178, #180): in the browser surface, the wrong input (login form, or the next prompt fired too early) is selected when DOM heuristics misidentify the chat widget.

These issues are useful signals of the architecture's edges: setup-time file IO, request cancellation in attackRunner, and input targeting all sit at the boundary between the core and whichever surface invokes it.

Cross-references

• Per-component deep dives live next to this page: CLI commands, SDK integration, and the browser extension.
• Evaluator catalog: see core/src/autonomous and the community tracker items #171, #172, #179.
• Release notes that affect the architecture (e.g., the apikey switch in v0.10.0) are summarized in CHANGELOG-equivalent release pages.

Related Pages

Related topics: OPFOR Overview & System Architecture, Evaluators, Patterns & Attack Coverage (OWASP + EU AI Act), Configuration, Reports, Telemetry & Operations

Runners & Entry Points (CLI, SDK, MCP Server, Browser Extension, Skills)

Overview

Opfor exposes its red-team assessment engine through five distinct runners, each tailored to a different environment. All runners share a common core (the attacker agent loop, evaluator registry, and target transport) but differ in how they are invoked, configured, and presented to the user.

The CLI entry composes subcommands, the SDK provides a constructor-based API, the MCP server exposes Model-Context-Protocol tools, the extension injects prompts through content scripts, and Skills package reusable behaviours shared across runners. Source: runners/cli/src/index.ts:1-40

CLI Runner

The CLI is registered through the top-level command dispatcher and exposes setup, run, and hunt subcommands.

• opfor setup bootstraps a new .opfor/ directory containing the configs/ subfolder used to persist run configurations. It is intended to be idempotent at the project root, but a known regression causes it to nest a new .opfor/ directory inside an existing one when invoked from within .opfor/configs/ (Issue #183). Source: runners/cli/src/commands/setup.ts:10-60
• opfor run executes a saved configuration, streams events, and writes a report. When the target agent returns an HTTP error, the current behaviour surfaces only the status code; users have requested that the body be included for triage (Issue #176). Source: runners/cli/src/commands/run.ts:25-120
• opfor hunt runs an interactive attacker loop without a pre-built config, useful for exploratory probing. Source: runners/cli/src/commands/hunt.ts:1-80

SDK Runner

The SDK is a thin programmatic wrapper intended for CI and integration tests. Construction uses API-key based authentication following the v0.10.0 breaking change (PR #168). Source: runners/sdk/src/opfor.ts:1-90

The public surface exposes typed builders for targets, strategies, and evaluators, alongside start(), pause(), resume(), and report() methods. The SDK is also the integration point requested for additional LLM providers such as AWS Bedrock and Google Vertex AI, which currently require custom transports (Issue #181). Type definitions for these options live alongside the implementation. Source: runners/sdk/src/types.ts:1-160

MCP Server Runner

The MCP runner boots an stdio-based server that advertises Opfor capabilities as tools to a host agent. It reuses the SDK internally and exposes start/pause/resume primitives plus reporting tools. Source: runners/mcp/src/index.ts:1-50 Tool handlers delegate to a shared OpforClient wrapper. Source: runners/mcp/src/server.ts:30-140 This allows MCP-compatible editors and agents to drive red-team runs without writing TypeScript directly.

Browser Extension Runner

The extension is a Manifest V3 package with three execution contexts:

1. Service worker orchestrates the attacker loop, manages pause/resume, and forwards prompts to the content script. Source: runners/extension/src/background/index.ts:1-200 The pause button has a documented latency of ~10s because the in-flight request is not aborted; community proposals request cancellation of the underlying fetch as soon as pause is pressed (Issues #177, #182).
2. Content script locates the agent's chat input on the active page and submits prompts. A reported bug causes it to target login-form text inputs instead of the chatbot input during red-team assessments (Issue #178). It is also observed to enqueue the next attack before the agent finishes its response, which can desynchronise the loop (Issue #180). Source: runners/extension/src/content/index.ts:1-180
3. Popup UI controls the active session and surfaces reports. Feature requests under this surface include steering the attacker mid-run (Issue #175), evaluating existing user↔agent conversations (Issue #171), uploading files to the target agent (Issue #173), and adding a Site-Specific Extension Execution evaluator (Issue #179). Source: runners/extension/src/popup/index.tsx:1-220

Skills

Skills are reusable, composable units (e.g. jailbreak templates, evaluator definitions, target adapters) that can be referenced from any runner. The registry resolves a skill by name and exposes metadata such as the runner compatibility matrix. Source: runners/skills/src/registry.ts:1-120 Skills keep attack logic decoupled from runner-specific transport concerns, which is what allows the same evaluator set to drive CLI, SDK, MCP, and extension flows. Source: runners/skills/src/index.ts:1-80

Cross-Runner Flow

flowchart LR
  User[Operator / Agent] --> CLI[CLI / SDK / MCP]
  User --> Ext[Browser Extension]
  CLI --> Core[Opfor Core Loop]
  Ext --> Core
  Core --> Skills[Skill Registry]
  Skills --> Evaluators
  Core --> Report

Each runner delegates the core loop to the same engine, then renders the output in its native form: terminal output, programmatic result, MCP tool response, or popup UI. This shared backbone is what enables the same configuration to be replayed across surfaces.

Related Pages

Related topics: OPFOR Overview & System Architecture, Runners & Entry Points (CLI, SDK, MCP Server, Browser Extension, Skills), Configuration, Reports, Telemetry & Operations

Evaluators, Patterns & Attack Coverage (OWASP + EU AI Act)

Purpose and Scope

Opfor ships a curated catalog of evaluators — declarative YAML patterns that describe adversarial attack flows, scoring logic, and expected behavior for an agent under test. Evaluators are the atomic unit of a red-team run; they are grouped into suites so users can opt into categories aligned with industry frameworks such as the OWASP Top 10 for LLM Applications and the OWASP Agentic AI Threats & Mitigations guide, as well as regulatory concerns drawn from the EU AI Act (transparency, harmful content, human oversight).

The catalog is intentionally split by surface area:

• evaluators/agent/... — direct attacks against conversational / tool-using agents.
• evaluators/mcp/... — attacks against Model Context Protocol servers (auth, tool boundaries).
• suites/agent/... — pre-bundled combinations that mirror deploy-time risk gates.

Source: evaluators/README.md:1-40 describes the discovery and execution model, and the path hierarchy under evaluators/agent/ confirms the category taxonomy (e.g. access-control/bfla, injection/jailbreaking).

Evaluator File Pattern

Each evaluator is a single YAML document following a consistent shape:

id: <stable-identifier>
category: <owasp | eu-ai-act | mcp>
severity: low | medium | high | critical
attack:
  type: <prompt-injection | jailbreak | bfla | rce | ...>
  payload: <inline or referenced dataset>
detection:
  judge: <llm | regex | function-call-trace>
  pass_when: <rule>
metadata:
  references:
    - https://owasp.org/...
    - https://artificialintelligenceact.eu/...

Concretely, the jailbreaking evaluator declares its category as injection and references OWASP LLM01 (Prompt Injection) in metadata, while the BFLA evaluator lives under access-control/ and binds to function-level authorization checks the agent performs (or fails to perform) when calling tools.

Source: evaluators/agent/injection/jailbreaking/evaluator.yaml:1-30 pins the pattern and OWASP tag. Source: evaluators/agent/access-control/bfla/evaluator.yaml:1-30 shows the access-control specific fields (function name, role assertion, expected deny).

Suites: Bundling Coverage by Risk Gate

Suites compose multiple evaluators so that a single CLI invocation covers an entire risk scenario. Two examples shipped today:

The pre-deploy-critical suite is the recommended smoke run before promoting an agent to production; it folds high-severity injection, jailbreak, and access-control checks into one pass. The harmful-content suite focuses on EU AI Act-style prohibited and high-risk categories (e.g. advice that enables harm, disallowed demographic inference).

Source: suites/agent/pre-deploy-critical.yaml:1-50 enumerates the included evaluator IDs. Source: suites/agent/harmful-content.yaml:1-40 enumerates the harmful-content evaluator IDs and per-prompt justification.

MCP Coverage and Community-Requested Evaluators

Beyond in-process agents, Opfor evaluates MCP servers for missing authentication, weak transport security, and excessive tool surface. The mcp/auth/ namespace is the canonical home for these checks:

Source: evaluators/mcp/auth/missing-authentication.yaml:1-25 registers the evaluator ID, the probe (anonymous call to a protected tool), and the pass condition (server must return 401/403 or equivalent).

The community has flagged additional coverage gaps that map directly to this surface, reinforcing why the evaluator pattern is pluggable rather than closed:

• Remote Code Execution evaluator — a requested addition to detect when the agent recommends or fetches-executes code from untrusted remote sources (#172, *Area: Evaluators / Attack coverage*).
• Site-Specific Extension Execution — extension-context attacks requested under the Browser Extension track (#179).
• File upload handling — file-borne attacks against the agent's ingestion path (#173).

These requests illustrate that the OWASP/EU AI Act coverage is a living catalog: new evaluators drop into the existing hierarchy (evaluators/<surface>/<category>/<attack>/evaluator.yaml) without requiring framework changes.

How an Evaluator Run Flows

flowchart LR
  A[Suite YAML] --> B[Resolver]
  B --> C[Evaluator YAML]
  C --> D[Attack Driver]
  D --> E[Target Agent / MCP]
  E --> F[Transcripts]
  F --> G[Judge LLM or Rules]
  G --> H[Pass / Fail per Evaluator]
  H --> I[Aggregated Report]

1. The runner loads a suite file (e.g. suites/agent/pre-deploy-critical.yaml) and resolves each evaluator: reference to a concrete YAML under evaluators/.
2. For every evaluator, an attack driver drives the configured payload against the target.
3. The transcript is handed to the judge declared in detection.judge — an LLM for semantic checks (jailbreaks, harmful content), a regex/function-trace rule for deterministic ones (BFLA, missing-auth).
4. Per-evaluator pass/fail is aggregated into the final report, which the CLI renders with HTTP response bodies included (per #176) so failures are debuggable.

Source: evaluators/README.md:40-90 documents the runner contract and judge pluggability.

Takeaways

• Evaluators are declarative, composable, and framework-tagged — the same YAML shape covers OWASP LLM risks, OWASP Agentic risks, and EU AI Act categories.
• Suites are the unit you actually run; pick a suite, not a single evaluator, when you want coverage.
• MCP and agent surfaces are evaluated with the same pipeline but live under distinct paths so that probes do not cross-contaminate.
• Open issues (#172, #173, #179) show the catalog is expected to grow along the same axes; contributing a new evaluator means adding one YAML file in the right subdirectory and, optionally, listing it from a suite.

Related Pages

Related topics: OPFOR Overview & System Architecture, Runners & Entry Points (CLI, SDK, MCP Server, Browser Extension, Skills), Evaluators, Patterns & Attack Coverage (OWASP + EU AI Act)

Configuration, Reports, Telemetry & Operations

This page covers the operational backbone of Opfor: how the project loads, validates, and persists configuration; how it generates assessment reports; how it emits telemetry and run metrics; and how the CLI orchestrates the end-to-end run lifecycle.

1. Configuration Model and Storage

Configuration is the entry point of every Opfor run. A typed schema defines the shape of an assessment, while a loader resolves it from the on-disk .opfor directory and merges multiple config layers.

The schema describes agents, attack strategies, evaluator plugins, target headers, and provider credentials. Field validation lives next to the schema so that invalid configs fail fast before any LLM call is made. Source: core/src/config/schema.ts:1-120

// core/src/config/schema.ts (illustrative excerpt)
export const OpforConfigSchema = z.object({
  version: z.string(),
  target: z.object({ url: z.string().url(), headers: z.record(z.string()).optional() }),
  attacker: z.object({ provider: z.string(), model: z.string(), strategy: z.string() }),
  evaluators: z.array(z.string()).default([]),
  apiKey: z.string().optional(),
});

opforConfig.ts is the single source of truth for the runtime config object. It owns the resolved configuration, handles environment-variable expansion (including the recent "expand env references in agent target headers" feature), and exposes getters consumed by the executor and report builder. Source: core/src/lib/opforConfig.ts:30-140

configLoader.ts walks the .opfor/ directory, parses YAML/JSON files from .opfor/configs/, and returns the merged config. Community issue #183 highlights a current limitation: invoking opfor setup while already inside .opfor/configs/ creates a nested .opfor/ directory rather than appending to the existing one. The loader is the component that must gain awareness of the parent .opfor/ root to fix this. Source: core/src/lib/configLoader.ts:45-110

2. CLI Operations: `run` and `setup`

The CLI is built around two primary verbs:

setup.ts is interactive: it prompts for the target agent URL, provider selection, API key, and attack strategy, then writes a templated YAML file into .opfor/configs/. It also expands environment references (e.g., ${OPFOR_API_KEY}) at write time so configs remain portable. Source: core/src/cli/commands/setup.ts:60-180

run.ts performs pre-flight validation against the schema, instantiates the attacker and evaluator providers via the factory, and hands control to the execution loop. It also installs signal handlers so that Ctrl+C triggers a graceful shutdown — relevant to issue #177/#182 where pause latency in the browser extension is reported. Source: core/src/cli/commands/run.ts:25-95

3. Report Generation

Reports are produced once an adversarial conversation completes. The pipeline is split into a builder (data assembly) and a renderer (presentation), which keeps the data model testable and the format swappable.

The builder aggregates transcript turns, evaluator verdicts, jailbreak success rates, and per-attack metadata into a normalized Report object. Source: core/src/reports/reportBuilder.ts:20-160

The renderer serializes the object to the configured output (terminal, JSON, or HTML) and writes it to the run directory. As raised in issue #176, the current renderer surfaces only the HTTP status code on agent errors; extending it to embed the full response body is tracked on the CLI roadmap. Source: core/src/reports/reportRenderer.ts:30-110

Feature request #171 extends this layer with "judge and create reports from existing conversations," which would let users feed an arbitrary transcript into the builder without re-running the attack loop.

4. Telemetry and Run Metrics

Opfor emits structured logs throughout the run lifecycle. logger.ts wraps a leveled logger (debug/info/warn/error) and tags every record with a run ID, component name, and ISO timestamp so that logs from concurrent runs can be filtered post hoc. Source: core/src/telemetry/logger.ts:1-90

runMetrics.ts tracks quantitative counters: attacks attempted, attacks successful, average latency per turn, tokens consumed, and evaluator pass rates. The executor updates these counters in runAgentLoop.ts and evaluatorLoop.ts, and the report builder reads them when assembling the summary header. Source: core/src/telemetry/runMetrics.ts:15-120

Centralized error handling lives in errors.ts, which maps low-level exceptions (network, provider, schema, evaluator) to typed OpforError subclasses. Each subclass carries a code, a user-facing message, and optional underlying-cause metadata that the renderer can include once issue #176 is resolved. Source: core/src/lib/errors.ts:10-140

Operational Workflow

flowchart LR
    A[opfor setup] --> B[.opfor/configs/*.yaml]
    B --> C[configLoader]
    C --> D[opfor run]
    D --> E[runAgentLoop]
    E --> F[evaluatorLoop]
    E --> G[telemetry/logger + runMetrics]
    F --> G
    E --> H[reportBuilder]
    F --> H
    H --> I[reportRenderer]
    I --> J[Run Report]

Known Operational Gaps

• Nested configs (#183): configLoader does not yet detect a parent .opfor/ when invoked recursively.
• Pause latency (#177, #182): The browser extension's pause path does not abort the in-flight request immediately.
• Error verbosity (#176): CLI reports expose only HTTP status codes; full response bodies are not yet attached.
• Post-hoc evaluation (#171): Reports can only be generated from a fresh run, not from an imported transcript.

These gaps inform the roadmap tracked across the SDK, CLI, and Browser Extension areas of the project.

Doramagic Pitfall Log

Found 33 structured pitfall item(s), including 2 high/blocking item(s). Top priority: Security or permission risk - Security or permission risk requires verification.

1. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Developers should check this security_permissions risk before relying on the project: feat: opfor setup wizard has no prompt for custom HTTP headers on url-transport MCP targets
• User impact: Developers may expose sensitive permissions or credentials: feat: opfor setup wizard has no prompt for custom HTTP headers on url-transport MCP targets
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: feat: opfor setup wizard has no prompt for custom HTTP headers on url-transport MCP targets. Context: Observed during installation or first-run setup.
• Evidence: failure_mode_cluster:github_issue | https://github.com/KeyValueSoftwareSystems/agent-opfor/issues/166

2. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Developers should check this security_permissions risk before relying on the project: feat: support for evaluating Site-Specific Extension Execution
• User impact: Developers may expose sensitive permissions or credentials: feat: support for evaluating Site-Specific Extension Execution
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: feat: support for evaluating Site-Specific Extension Execution. Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_issue | https://github.com/KeyValueSoftwareSystems/agent-opfor/issues/179

3. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: v0.10.0
• User impact: Upgrade or migration may change expected behavior: v0.10.0
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: v0.10.0. Context: Observed during installation or first-run setup.
• Evidence: failure_mode_cluster:github_release | https://github.com/KeyValueSoftwareSystems/agent-opfor/releases/tag/v0.10.0

4. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/KeyValueSoftwareSystems/agent-opfor/issues/171

5. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.host_targets | https://github.com/KeyValueSoftwareSystems/agent-opfor

6. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: bug: Nested .opfor configs
• User impact: Developers may misconfigure credentials, environment, or host setup: bug: Nested .opfor configs
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: bug: Nested .opfor configs. Context: Observed when using node, linux
• Evidence: failure_mode_cluster:github_issue | https://github.com/KeyValueSoftwareSystems/agent-opfor/issues/183

7. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: bug: Significant delay in registering pause button clicks.
• User impact: Developers may misconfigure credentials, environment, or host setup: bug: Significant delay in registering pause button clicks.
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: bug: Significant delay in registering pause button clicks.. Context: Observed when using node, linux
• Evidence: failure_mode_cluster:github_issue | https://github.com/KeyValueSoftwareSystems/agent-opfor/issues/182

8. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: bug: browser extension targets login form instead of chatbot input during red-team assessment
• User impact: Developers may misconfigure credentials, environment, or host setup: bug: browser extension targets login form instead of chatbot input during red-team assessment
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: bug: browser extension targets login form instead of chatbot input during red-team assessment. Context: Observed when using node, linux
• Evidence: failure_mode_cluster:github_issue | https://github.com/KeyValueSoftwareSystems/agent-opfor/issues/178

9. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: bug:browser extension generates next attack before the agent has completed its response
• User impact: Developers may misconfigure credentials, environment, or host setup: bug:browser extension generates next attack before the agent has completed its response
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: bug:browser extension generates next attack before the agent has completed its response. Context: Observed when using node, linux
• Evidence: failure_mode_cluster:github_issue | https://github.com/KeyValueSoftwareSystems/agent-opfor/issues/180

10. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: feat: add first-class support for additional LLM providers
• User impact: Developers may misconfigure credentials, environment, or host setup: feat: add first-class support for additional LLM providers
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: feat: add first-class support for additional LLM providers. Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_issue | https://github.com/KeyValueSoftwareSystems/agent-opfor/issues/181

11. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/KeyValueSoftwareSystems/agent-opfor/issues/183

12. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/KeyValueSoftwareSystems/agent-opfor/issues/182

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using agent-opfor with real data or production workflows.

• bug: Nested .opfor configs - github / github_issue
• bug: Significant delay in registering pause button clicks. - github / github_issue
• feat: add first-class support for additional LLM providers - github / github_issue
• bug:browser extension generates next attack before the agent has complet - github / github_issue
• bug: Significant delay in registering pause button clicks. - github / github_issue
• feat: support for evaluating Site-Specific Extension Execution - github / github_issue
• bug: browser extension targets login form instead of chatbot input durin - github / github_issue
• feat: Show the response of agent errors instead of just an HTTP status c - github / github_issue
• feat: Allow the user the steer the attacker agent during testing - github / github_issue
• feat: Ability to judge and create reports from the conversations between - github / github_issue
• feat: evaluator for remote code execution - github / github_issue
• feat: OPFOR getting the ability to upload files to agent - github / github_issue