Autonomous long-running realistic user simulation with embedded attacks

[Maximus7745]

Hi!
I'm working with the GHOSTS API and would like to implement an autonomous system that simulates realistic user activity on NPCs over extended periods (1 day to 1 week).
Goal:
Build an autonomous agent that:
Generates realistic daily user behavior - indistinguishable from actual human activity
Periodically injects attack techniques (visiting malicious domains, downloading suspicious files, lateral movement attempts) at configurable intervals
Maintains consistent "user personas" across the simulation period
Runs continuously without requiring manual prompts
Current setup:
GHOSTS API is up and running
I can send JSON instructions to NPCs to trigger specific actions
I have a local LLM (Ollama with mistral) that can plan sequences of actions
n8n is available as a workflow engine
Questions:
Are there any built-in capabilities or reference implementations for autonomous long-running user simulation?
Is there a recommended architecture for a loop where an LLM continuously plans the next action and dispatches it to GHOSTS?
Is n8n the intended orchestration layer for such a loop - e.g., a workflow that asks the LLM for the next action and forwards it to GHOSTS? Are there any example workflows or templates for this?
Are there existing activity generators / scenario templates that produce realistic multi-day user behavior out of the box?
Has anyone implemented similar "autonomous NPC" setups, and what was the approach?
Any pointers to relevant documentation, examples, or architectural advice would be greatly appreciated.
Thanks!

[sei-dupdyke]

Great question! This is close to the primary use case we build for, so let me say what ships today, and where you will have to write/configure because we don't — yet!

We ship in three layers that you can config/compose:

1. scheduled narrative/attack injects via Scenarios + Executions
2. LLM-driven content/decisions via n8n workflows
3. deterministic baseline behavior on the client

The most important piece of advice up front: you probably should not put the LLM in the per-action loop for every NPC. That's the design most people want first, and it gets expensive, drifty, and unstable over a multi-day run.

Think:

Tier 3  Scenario / Execution engine   ← narrative + attack injects at T+X, cron, ATT&CK TTPs
Tier 2  n8n workflows + Ollama        ← content, decisions, social/belief state evolution. This is the primary location for social/cognative activity.
Tier 1  Client timelines (Loop=true)  ← the 24/7 baseline. No LLM. No prompting. Runs for weeks. This is the primary location for cyber activity.

Tier 1 — baseline behavior is already autonomous

Your "operates continuously with no manual prompting" requirement is mostly satisfied by the client itself. A timeline handler with "Loop": true runs forever until you replace it. The knobs are:

• UtcTimeOn / UtcTimeOff — office hours per handler. The client applies up to ±30 minutes of random jitter to these boundaries, so a group of NPCs doesn't all start at 09:00:00.
• DelayBefore / DelayAfter — accept random ranges, not just fixed values.
• ScheduleType: "Cron" + Schedule — for "check email every 20 minutes on weekdays" style behavior. See src/Ghosts.Api/config/timelines/Cron.json.
• Per-handler mixing: an accountant gets Outlookv2 + Excel + BrowserChrome + Print; a developer gets Ssh + Command/Bash + BrowserFirefox.

Build 3–5 role archetypes this way, push them to machine groups, and you have a week of plausible activity with zero LLM calls. Get this right and you have ~80% of what makes the telemetry.

If you're running many NPCs and the audience won't be looking at the desktop/host directly, then Ghosts.Client.Lite gives you the same network/file telemetry at 50–200MB per client instead of 0.5–2GB (docs/core/lite.md).

Tier 2 — n8n + Ollama for content and decisions

n8n is the intended orchestration layer as of v9.0 — the old in-process animation jobs were reimplemented as workflows (that you can edit if you like). Templates ship in configuration/n8n-workflows/:

• GHOSTS Social Graph.json, GHOSTS Connections.json — who knows whom, evolving
• GHOSTS Belief.json — Bayesian belief state per NPC
• GHOSTS Preferences.json
• GHOSTS Post to Social Media.json — n8n AI Agent + Ollama Chat Model node, per NPC
• GHOSTS NPC Chat.json, GHOSTS Real-time Chat.json

Bootstrap/provisioning lives in configuration/n8n-bootstrap/ and the API activates workflows automatically when a scenario references them (N8N_API_URL / N8N_API_KEY).

What you'll need to write (small, hopefully)

None of the shipped workflows push a timeline down to a client. They animate NPC cognitive/social state and post to the local Pandora/chat services at the API level. If you want clients to actually do something, add one HTTP node to the end of your workflow:

POST /api/machineupdates
{
  "machineId": "<guid>",
  "type": "TimelinePartial",
  "update": { "TimeLineHandlers": [ { "HandlerType": "BrowserChrome", "Loop": false, "TimeLineEvents": [ ... ] } ] }
}

or POST /api/machineupdates/group/{groupId} to hit a whole group. TimelinePartial means "add this behavior" rather than "replace the timeline", so injects don't disturb the baseline from Tier 1. Delivery is websocket-first via SignalR with a DB-queue fallback if the client is offline.

That is essentially the difference between narratives at the API level and clients actually doing activity.

Tier 3 — embedded attacks on a schedule

For "insert offensive techniques at chosen intervals," the Scenario/Execution model is what you want (src/Ghosts.Api/Infrastructure/Models/Scenarios.cs):

• ThreatActor with Ttps (MITRE ATT&CK technique IDs), type (state/criminal/hacktivist/insider), capability
• Inject with a Trigger like T+10m
• UserPool (role + count) — on execution creation these auto-generate execution-scoped NPCs grouped by Campaign/Enclave/Team
• GameMechanics with DurationHours, escalation ladder, branching logic
• ScenarioTimelineEvent with TriggerKind = PointInTime | Scheduled | Triggered

ExecutionWorkflowScheduler polls every 10 seconds and fires due items: PointInTime items at their T+Xm offset from execution start, Scheduled items on their cron via the n8n webhook. Lifecycle is POST /api/executions → /start → /pause → /stop, with per-item status and an event log you can query (/events, /timeline-items).

There's also GET /api/attack/techniques and /api/attack/groups over the bundled ATT&CK enterprise data, so you can resolve a threat actor's real TTP set programmatically rather than hardcoding.

For the actual malicious activity, use the real handlers — they already do everything on your list:

What you want	Handler
Visit a malicious domain	BrowserChrome / BrowserFirefox / BrowserEdge / Curl (host the "malicious" site in Pandora)
Download / run a suspicious file	browser download, Curl, ExecuteFile
Lateral movement	PowerShell, Command/Bash, Ssh, Wmi, Rdp, Sftp
Data staging / exfil	Sftp, Ftp, Sharepoint, Watcher

Also, every TimelineEvent accepts a TrackableId. Tag your injected malicious events with one, and GET /api/trackables/{id} gives you the execution history for that specific inject across every machine that ran it. That's what turns "we ran some attacks in the noise" into a gradeable exercise where you can prove what the blue team did and didn't catch.

Where we still have work

You asked whether ready-made generators and templates exist. Partly...

1. No red-team / attack workflow template ships. All seven bundled n8n workflows are social, belief, chat, and preference oriented. Nothing takes a ThreatActor's TTP list and emits a corresponding timeline.
2. No multi-day scenario template ships. src/Ghosts.Api/config/timelines/*.json are minimal per-handler samples — one or two events each to show syntax. There is nothing in the repo resembling "5 days of a 40-person office with an intrusion chain woven through it." We have done this manually up to recently, but it is on the radar to look at when I get time.
3. Scenario-compiled events don't yet produce real telemetry. When an execution starts, ExecutionService.BuildTimelineForNpc turns each scenario timeline event into an npc-scenario-action command carrying the event's description string. The client receives it, reports it back, and the execution item advances and closes the loop correctly — but the client does not enact it. It won't browse, mail, or run a command from a compiled scenario event. Also, every assigned NPC currently receives an identical timeline (no per-NPC filtering). So today: use Scenarios for narrative structure, scheduling, and tracking; use hand-authored timelines and n8n-pushed TimelinePartial updates for behavior that shows up in your network sensors.
4. Time offsets are minutes-only. ParseTimeOffsetMs matches T+(\d+)m. T+2h or T+1d parses to 0 and fires immediately. For a week-long run, express everything in minutes — day 3 at 09:00 is T+2940m. Fair to call this a wart; it needs fixing. What can I say, date/time is hard!
5. Triggered / conditional triggers aren't evaluated server-side. You can store OnDetect-style triggers on a scenario event, but only PointInTime and Scheduled are acted on. Event-driven injects need to be driven from your own n8n logic today.
6. Memory probably needs work in your use case. Flat-file history, string-matched per agent. At your durations and NPC counts, plan on persisting decision history in the DB (NPC activity records are the natural home) rather than extending that file. How should we model this? Do agents never forget? Or do they? If they do, how should that mechanism work?
7. On "indistinguishable from actual human activity" — I'd temper that goal. GHOSTS produces genuinely plausible artifacts, and against a SOC looking for adversary behavior it holds up well. Against a team specifically hunting the simulation, there are tells: Jitter is drawn from fixed distributions, there are no sick days or vacations or deadline crunches, clients heartbeat to the API on a schedule, and mouse/keyboard-level fidelity only exists where you use the Clicks handler. Budget your effort accordingly: variance in the baseline buys you far more realism than sophistication in the attack chain.

If I were building your setup this week

1. Author 3–5 role archetype timelines with office hours and randomized delays. Push to machine groups. Let it run a full 24 hours and look at what your sensors actually recorded. Fix the baseline before adding anything.
2. Generate your NPC population (Animator / UserPools). Confirm each NPC's identity is queryable.
3. Add one n8n workflow per role: cron trigger → GET /api/npcs/{id} → Ollama for content and next action → POST /api/machineupdates with a TimelinePartial. Copy the LLM node wiring from GHOSTS Post to Social Media.json. This is your autonomous loop, and n8n gives you retries and an execution log for free — which matters a lot on day 4 at 2am.
4. Model the intrusion as a Scenario: ThreatActor with real ATT&CK TTPs, Injects at T+Xm offsets. Each inject is a workflow that pushes a TrackableId-tagged TimelinePartial to specific machines. Start the execution and let the scheduler fire them.
5. Grade with /api/trackables/{id} and the execution event log.

Steps 1–2 work out of the box. Step 3 is one HTTP node beyond what ships. Step 4 is where you're writing the most net-new content.

HTH. Anything specific, we can enter an issue and try to get it rectified as quickly as possible.