AI Actor Behavior Model

[sehkone]

AI Actor Behavior Model

This document defines the behavior model for AI Actor — an autonomous AI-driven attacker on the attacker axis. It covers how AI Actor behaviors are defined, what attack scenarios they execute, and how the Generator implements them in phases. For the overall platform architecture, see the overview document. For the scenario input format, see the Scenario Definition Schema.

---

1. Purpose

Phase 1 generates datasets using human attackers — pre-defined tool sequences executed on a fixed schedule. This works for traditional threat scenarios but does not capture how AI-driven attackers behave in practice.

AI Actor introduces an attacker that:

• Plans autonomously — decomposes a high-level objective into attack steps
• Adapts to the environment — chooses next actions based on observed responses
• Operates at machine speed — produces traffic patterns distinct from human attackers

This document defines how AI Actor behaviors are modeled, how they differ from other attacker types, and how the Generator implements them incrementally.

---

2. Attacker Type Spectrum

The attacker axis defines four types with increasing autonomy:

Type	Planning	Execution	Adaptation	Generator Implementation
human	Scenario author defines steps	Tools run on schedule	None (fixed sequence)	Phase 1: Orchestrator runs tools in declared order
scripted	Scenario author defines steps	Tools run automatically	None (fixed sequence, machine timing)	Phase 1: Same as human but with uniform timing
ai_assisted	Scenario author defines strategy	AI selects tools/parameters	Limited (AI chooses within constraints)	Phase 2: LLM picks parameters, Orchestrator executes
ai_actor	AI defines strategy from objective	AI drives execution	Full (reacts to environment)	Phase 2+: LLM agent loop with tool access

Key distinctions:

• human vs scripted: Same steps, different timing. Human has irregular intervals (thinking time); scripted has uniform, fast intervals.
• scripted vs ai_assisted: Scripted follows a fixed script. AI-assisted has a human-defined strategy but the AI picks specific tools, targets, or parameters within that strategy.
• ai_assisted vs ai_actor: AI-assisted operates within a human-defined plan. AI Actor receives only an objective and builds its own plan.

---

3. Proposed Approach — Phased Implementation

3.1 Phase 2 Early: Simulation

Use template-based behavior patterns that mimic AI Actor characteristics without running an actual LLM.

How it works:

1. Define behavior templates — parameterized attack sequences with AI-style timing and branching rules
2. Templates include conditional logic: "if port 445 open → try SMB exploit; else → try SSH"
3. Timing model: fast, uniform intervals with brief processing pauses (simulating LLM inference time)

Pros: Deterministic, reproducible, no API cost, fast execution
Cons: Cannot truly adapt; branching is limited to pre-defined conditions

Example template:

behavior: systematic-reconnaissance
timing: { base_interval: 2s, variance: 0.5s }
steps:
  - action: port_scan
    targets: "{{ subnet }}"
    on_result:
      - condition: "open_ports includes 445"
        next: smb_exploit
      - condition: "open_ports includes 22"
        next: ssh_bruteforce
      - default: next_subnet

3.2 Phase 2 Late: Hybrid

LLM decides strategy; existing attack tools execute.

How it works:

1. LLM receives the objective + current environment state (scan results, access gained so far)
2. LLM outputs a structured action (tool name, target, parameters)
3. Orchestrator executes the action using existing tool wrappers (nmap, Metasploit, etc.)
4. Results are fed back to the LLM for the next decision

Objective + Environment State
        ↓
   LLM Decision
        ↓
  Structured Action (tool, target, params)
        ↓
  Orchestrator executes tool
        ↓
  Result captured → fed back to LLM
        ↓
  (loop until objective met or limit reached)

Pros: Genuinely adaptive, produces realistic AI attacker behavior
Cons: Non-deterministic, API cost per run, slower execution

3.3 Phase 4: Full Autonomous

Real LLM agent with direct tool access operating inside the emulation environment, capable of large-scale and long-duration campaigns.

This phase builds on Phase 2 Late infrastructure but removes the Orchestrator as intermediary — the AI Actor interacts with the environment directly.

3.4 Recommended Path

Proposed direction: Start with simulation (3.1) to establish the traffic pattern framework and Ground Truth extensions. Move to hybrid (3.2) once Phase 1 infrastructure is proven and the cost/reproducibility trade-offs are understood.

Open question: Should the simulation phase use recorded traces from real LLM agent runs (record once, replay many times) to combine realism with reproducibility?

---

4. Initial Knowledge Model

An AI Actor's starting knowledge determines its reconnaissance behavior and overall traffic footprint.

Level	What the AI Actor Knows	Effect on Traffic
black_box	Target subnet only	Heavy scanning, broad reconnaissance, many failed attempts
gray_box	Partial host/service inventory	Targeted scanning, fewer probes, faster progression
white_box	Full network topology and services	Minimal reconnaissance, proceeds directly to exploitation

4.1 Scenario Definition Integration

The knowledge level can be expressed as a new field in activities.attack:

activities:
  attack:
    - attacker: ai_actor
      knowledge: gray_box
      known_hosts: ["10.0.1.10", "10.0.1.50"]
      known_services: { "10.0.1.10": ["smb/445", "rdp/3389"] }
      objective: "Exfiltrate files from the database server"

For simulation (Phase 2 Early), knowledge determines which template branch to follow. For hybrid (Phase 2 Late), knowledge is included in the LLM's initial prompt.

Open question: Should knowledge be a top-level environment axis or remain per-activity? If it becomes an axis, it increases the combinatorial space but enables systematic coverage.

---

5. Goal-Based vs Procedure-Based Activities

5.1 Current Model (Procedure-Based)

Phase 1 attack activities are defined as explicit procedures:

activities:
  attack:
    - technique: T1046
      tool: nmap
      target: "10.0.1.0/24"
      schedule: { start: "01:00:00", duration: "5m" }
    - technique: T1210
      tool: metasploit
      target: "10.0.1.10"
      schedule: { start: "01:10:00", duration: "30m" }

The scenario author decides every step. The Generator executes them in order.

5.2 AI Actor Model (Goal-Based)

AI Actor activities are defined as objectives:

activities:
  attack:
    - attacker: ai_actor
      objective: "Gain access to the database server and exfiltrate customer records"
      knowledge: gray_box
      constraints:
        max_duration: "2h"
        allowed_tools: ["nmap", "metasploit", "impacket"]
        target_scope: "10.0.1.0/24"
      schedule: { start: "01:00:00" }

The AI Actor decides:

• Which hosts to scan first
• Which vulnerabilities to exploit
• How to move laterally
• How to exfiltrate data

The scenario author controls:

• The high-level objective
• Time and scope constraints
• Available tools
• Starting knowledge

5.3 Coexistence

A single scenario can mix procedure-based and goal-based activities:

activities:
  normal:
    - type: web_browsing      # procedure-based (always)
      ...
  attack:
    - technique: T1046         # procedure-based (human/scripted)
      tool: nmap
      ...
    - attacker: ai_actor       # goal-based
      objective: "..."
      ...

Open question: Should ai_assisted use a hybrid format — procedure-based steps where some parameters are marked as "AI decides"? For example: target: "{{ ai_select: most_vulnerable }}".

---

6. Behavior Catalog

AI Actor techniques, organized by kill chain phase. Focus on techniques where AI-driven execution produces observably different traffic from human execution.

6.1 Reconnaissance

Technique	AI Actor Behavior	Difference from Human
T1046 Port Scan	Systematic full-range scan or LLM-guided selective scan	Human: selective ports; AI: broader, faster, more uniform intervals
T1018 Remote System Discovery	Parallel subnet enumeration	Human: sequential; AI: parallelized, exhaustive
T1082 System Information Discovery	Automated parsing and immediate follow-up	Human: manual review with pauses

6.2 Initial Access / Exploitation

Technique	AI Actor Behavior	Difference from Human
T1210 Exploitation of Remote Services	Rapid exploit selection based on scan results	Human: manual research; AI: instant tool selection
T1078 Valid Accounts	Credential stuffing at machine speed	Human: deliberate, few attempts; AI: rapid, systematic
T1190 Exploit Public-Facing Application	Automated vulnerability probing	Human: targeted; AI: comprehensive enumeration

6.3 Lateral Movement

Technique	AI Actor Behavior	Difference from Human
T1021 Remote Services	Multi-target parallel access	Human: one-at-a-time
T1570 Lateral Tool Transfer	Automated staging on multiple hosts	Human: selective staging

6.4 Exfiltration

Technique	AI Actor Behavior	Difference from Human
T1048 Exfiltration Over Alternative Protocol	Protocol selection based on available channels	Human: pre-planned; AI: adaptive
T1041 Exfiltration Over C2 Channel	Continuous, optimized data transfer	Human: batch transfers with pauses

This catalog is not exhaustive. It highlights techniques where AI Actor traffic is distinguishable from human traffic. Techniques where the traffic is identical regardless of attacker type (e.g., running the same exploit binary) are handled by the existing Phase 1 framework without modification.

---

7. Traffic Differentiation

7.1 Timing Patterns

Dimension	Human	Scripted	AI Actor
Inter-action interval	Irregular (5–60s), long pauses for thinking	Fixed interval (e.g., every 2s)	Short, near-uniform (1–3s) with periodic spikes (LLM inference time)
Session duration	Variable, includes idle time	Predictable, matches script	Continuous until objective met or limit hit
Reaction to results	Delayed (reads, thinks, decides)	Immediate (no interpretation)	Brief delay (LLM processing), then immediate
Active hours	Business hours or specific windows	24/7 if configured	24/7, no fatigue

7.2 Exploration Patterns

Dimension	Human	AI Actor
Target selection	Experience-based, skips unlikely targets	Systematic enumeration or LLM-guided prioritization
Depth vs breadth	Deep focus on promising leads	Broad initial scan, then deep dive on best candidates
Failed attempt handling	May abandon after few failures	Retries systematically, tries alternatives
Tool chaining	Manual, sequential	Automated, may parallelize

7.3 LLM Interaction Traffic

When the AI Actor uses an external LLM (hybrid or full autonomous mode), this creates a distinctive traffic pattern:

• HTTPS requests to LLM API endpoints (e.g., api.openai.com, api.anthropic.com)
• Characteristic request/response sizes (prompts: 1–10 KB, responses: 0.5–5 KB)
• Regular cadence: one LLM call per action cycle
• This traffic is captured in PCAP and provides a unique signal for detecting AI-driven attacks

Open question: Should LLM interaction traffic be captured as a separate artifact (like ai_actor/llm_calls.jsonl) or is PCAP sufficient?

---

8. Ground Truth Extensions

AI Actor records need additional metadata beyond the standard Ground Truth fields defined in the Ground Truth Definition.

8.1 Proposed Additional Fields

Field	Type	Required	Description
attacker_type	string	yes (when attacker is not human)	scripted, ai_assisted, ai_actor
knowledge	string	no	Initial knowledge level: black_box, gray_box, white_box
objective	string	no	High-level goal given to the AI Actor
decision_ref	string	no	Reference to decision trace record (see Section 9)

8.2 Example Record

{"scope": "session", "label": "anomaly", "category": "attack", "campaign_id": "ai-recon-1", "step": 1, "start": "2025-06-01T02:00:00Z", "end": "2025-06-01T02:00:12Z", "source": "ai-actor-001", "target": "win-001", "session_type": "network", "protocol": "tcp", "src_ip": "10.0.2.100", "src_port": 48001, "dst_ip": "10.0.1.10", "dst_port": 445, "technique": "T1046", "phase": "reconnaissance", "tool": "nmap", "attacker_type": "ai_actor", "knowledge": "gray_box", "objective": "Exfiltrate database records", "decision_ref": "decision-001"}

Open question: Should attacker_type be a standard field on ALL Ground Truth records (including human), or only appear on AI Actor records? Making it standard would simplify filtering but adds a field to every record.

---

9. Decision Trace

9.1 Purpose

The Decision Trace records the AI Actor's reasoning process — what it observed, what it considered, and why it chose each action. This data is valuable for:

• Security research: Understanding AI attacker decision patterns
• Detection development: Building models that recognize AI-driven attack reasoning
• Debugging: Diagnosing unexpected AI Actor behavior during generation
• Reproducibility: Replaying decisions to reconstruct a scenario

9.2 Format

Stored as ai_actor/decisions.jsonl within the Dataset Bundle:

dataset_bundle/
  ...
  ai_actor/
    decisions.jsonl     ← Decision Trace
  ground_truth/
    manifest.jsonl

9.3 Record Schema

Field	Type	Required	Description
decision_id	string	yes	Unique identifier (referenced by Ground Truth decision_ref)
campaign_id	string	yes	Links to the Ground Truth campaign
step	number	yes	Step within the campaign
timestamp	string	yes	ISO 8601 timestamp of the decision
observation	object	yes	What the AI Actor observed (scan results, access state, etc.)
reasoning	string	yes	Summary of why this action was chosen
action	object	yes	The action taken (tool, target, parameters)
alternatives	object[]	no	Other actions considered but not chosen

9.4 Example

{"decision_id": "decision-001", "campaign_id": "ai-recon-1", "step": 1, "timestamp": "2025-06-01T02:00:00Z", "observation": {"known_hosts": ["10.0.1.10"], "known_services": {"10.0.1.10": ["smb/445", "rdp/3389"]}}, "reasoning": "SMB port 445 is open on target. SMB vulnerabilities are common and high-impact. Prioritizing SMB enumeration before trying RDP.", "action": {"tool": "nmap", "target": "10.0.1.10", "params": "--script smb-vuln*"}, "alternatives": [{"tool": "nmap", "target": "10.0.1.10", "params": "--script rdp-vuln*"}]}

9.5 Generation

• Simulation mode (Phase 2 Early): Decision Trace is generated from template branching logic. reasoning is a templated string describing the branch condition.
• Hybrid mode (Phase 2 Late): Decision Trace is captured from actual LLM responses. reasoning is extracted from the LLM's chain-of-thought output.

Open question: In simulation mode, the Decision Trace is synthetic. Is it still useful, or should it only be generated in hybrid/full autonomous modes?

---

10. Safety Boundaries

AI Actor operates inside the emulation environment. The following safeguards prevent unintended impact.

10.1 Network Isolation

• Emulation environment has no outbound internet access except to designated LLM API endpoints (hybrid mode only)
• All LLM API calls go through a controlled proxy that logs requests and enforces rate limits
• DNS resolution is internal only (no external domain resolution)

10.2 Scope Constraints

The Scenario Definition limits what the AI Actor can target:

constraints:
  target_scope: "10.0.1.0/24"          # IP range the AI Actor may target
  allowed_tools: ["nmap", "metasploit"] # Whitelist of available tools
  max_duration: "2h"                     # Hard time limit
  max_actions: 500                       # Maximum number of actions

The Orchestrator enforces these constraints. Any action outside scope is blocked and logged.

10.3 Kill Switch

• The Orchestrator monitors AI Actor progress
• If the AI Actor exceeds resource limits, enters a loop, or attempts out-of-scope actions repeatedly, the Orchestrator terminates the actor and records the termination in Ground Truth
• Termination is a normal outcome — it means the AI Actor was contained, which is itself useful data

---

11. Open Questions

The following decisions should be resolved before AI Actor implementation begins:

#	Question	Impact	Options
1	Start with simulation or hybrid?	Development effort, cost, realism	Simulation first (recommended), or jump to hybrid if LLM costs are acceptable
2	Record-and-replay for reproducibility?	Whether AI Actor datasets are reproducible	Record LLM decisions once, replay deterministically; or accept non-determinism as a feature (diverse datasets)
3	knowledge as axis or per-activity field?	Combinatorial space, scenario flexibility	Per-activity (simpler) vs axis (systematic coverage)
4	attacker_type on all Ground Truth records?	Data schema, filtering convenience	All records (consistent) vs AI-only (lighter)
5	Decision Trace in simulation mode?	Overhead, usefulness	Generate synthetic traces (completeness) vs skip (simplicity)
6	LLM interaction as separate artifact?	Bundle structure, analysis convenience	Separate ai_actor/llm_calls.jsonl vs PCAP-only
7	Cost budget per scenario?	Feasibility of hybrid mode	Define acceptable cost range; consider open-source LLMs as alternative
8	Paired datasets (human + AI Actor)?	Evaluation methodology	Same objective executed by human and AI Actor for comparison; increases generation effort but enables direct comparison