Planned features and integrations for the Xzopia platform.
Clients contact support via their preferred channel; tickets appear in ITFlow automatically with no manual triage.
Priority order: Teams → WhatsApp → Tray Agent
Both integrations deployed as MCP servers on Server 4 (dev MCP). Metrics feed the SecureAgent Portal Network tab and Cyber Essentials firmware compliance monitoring.
/schedule check-gdap-expiry every Monday at 08:00Daily automated vulnerability management across all 350 managed devices.
Schedule: 03:00 CVE pull → 03:30 cross-reference → 04:00 remediation → 06:00 reports + tickets → 07:00 email summary
Severity SLA: Critical/High = same day automated; Medium = 48 hours; Low = 7 days
Supply-chain feed (extend this item): The Shai-Hulud/Miasma campaign (2026) demonstrated the need to monitor npm/PyPI supply-chain advisories alongside OS CVEs. The daily 03:00 feed should include:
https://registry.npmjs.org/-/npm/v1/security/advisories) for packages used across Server 3 (live MCP), Server 4 (dev MCP), and any client-managed Node.js servicesnpm audit run against all project directories on S3 and S4 nightly; alert on any new High/Criticalxzopia-deploy workflow (dead-drop detection)Triggered by: Shai-Hulud/Miasma supply-chain audit 2026-06-11. Manual audit clean; ignore-scripts hardening applied to WSL + S4. See LESSONS_LEARNED.md #75.
Automated weekly external penetration test against both Xzopia servers using open-source tools.
Skill: .claude/skills/security-pentest/SKILL.md
Schedule: Every Monday — /security-pentest --target all --ssh-key ~/.ssh/xzopia_server1 --ssh-port 2222
Tools: nmap · nikto · nuclei · sslyze · lynis
Checks:
Cyber Essentials mapping:
| Control | Tool |
|---|---|
| CE1: Firewalls | nmap — unexpected open ports |
| CE2: Secure Configuration | nikto + nuclei — default configs, version disclosure |
| CE3: User Access Control | nikto — auth bypass, exposed admin panels |
| CE4: Malware Protection | lynis — AV/malware scanner present |
| CE5: Patch Management | nuclei CVEs + lynis — unpatched vulnerabilities |
Targets:
213.171.194.170 — rmm/api/mesh.xzopiasecure.com109.228.38.65 — psa/vault/docs/kb/portal.xzopiasecure.comReports: Saved to reports/pentest-YYYY-MM-DD.md (gitignored — not committed to repo)
Future enhancement: Auto-create ITFlow ticket when Critical or High findings are found; email summary to simon@xzopia.com.
See docs/auto-kb-setup.md for full technical specification.
When an ITFlow ticket is resolved, trigger a Claude API call to generate a structured KB article from the resolution notes. Article saved as a draft in Wiki.js and sent to the assigned tech for review. On approval, published to kb.xzopiasecure.com.
Value: Turns every resolved ticket into reusable documentation automatically.
Key metrics to track:
Implementation dependencies: ITFlow webhook support, Wiki.js API token, Claude API key.
See src/commands/migrate-ninjaone-trmm.ts and .claude/skills/migrate-ninjaone-trmm/SKILL.md.
Phase 1 (client structure migration) is built. Phase 2 (agent migration for 350 devices)
requires client-by-client planning to minimise disruption. Cancel NinjaOne subscription
only after all devices migrated and verified.
Status: IN PROGRESS — shut down 18 Jun 2026, cancellation pending
Orphaned legacy VPS managed by Xzopia on behalf of a customer. All services migrated off years ago; box dormant since April 2022.
Findings (18 Jun audit):
access_log 0 bytes; archives end April 2022). No live FTP, no active sub-users.masscan found at ~/.cache/.masscan (mass port-scanner); three 14–15 byte random-named hidden dotfiles in the home dir dated 8–9 Apr 2022 — fits the profile of botnet/scanner infection markers. Legit setup ~5 Apr, compromise markers ~8–9 Apr, then dormant silence. Evidence left in place (not opened/executed) pending snapshot.Action taken:
shutdown -h now executed 18 Jun 2026 (reversible halt — box off, not deleted).Broader action: We found a likely-compromised host on infrastructure we host-but-don't-manage. Before migrating other dormant Astutium boxes, run the same audit: check for hidden files, mass-scanners, and unexpected processes.
See docs/webserver-migration.md.
Consolidate all client web hosting from Astutium and Fasthosts (multiple accounts) to
a single managed Fasthosts infrastructure. Includes setup-webserver skill for
standardised Linux web server setup (Apache/Nginx, PHP, MySQL, SSL, UFW, ClamAV, Fail2Ban).
TacticalRMM monitoring policy Xzopia-Standard-Web covers: HTTP/HTTPS uptime,
SSL cert expiry (<30 days warning, <7 days critical), disk, MySQL running.
See .claude/skills/deploy-pipeline/SKILL.md.
5-stage mandatory deployment gate: pre-flight → setup → audit → pentest → sign-off.
Documented as a standing rule in CLAUDE.md. Apply to all future server setups.
Status: documented to runbook standard — productisation FUTURE
The NinjaOne → TacticalRMM migration tooling and methodology is a candidate white-label service for other MSPs switching from NinjaOne (or any RMM) to TacticalRMM.
Reusable engine (separate from Xzopia-specific config):
docs/scripts-library-standard.md.--include-unknown; NAPS2 pinned; Adobe ARP-GUID adoption pattern. See LESSONS_LEARNED.md #90.docs/tacticalrmm-policy-design.md.Per-client config (Xzopia-specific — must be abstracted away):
scripts/packages/baseline.psd1Productisation path: Extract the engine into a standalone CLI with config-file-driven client list + exclusion/merge rules. The Xzopia run becomes one config file; other MSP runs swap in theirs. Dry-run report and baseline CSV become deliverables in the white-label service. NinjaOne's own curated scripts are licence-restricted against republishing — scripts must be rewritten, not copied.
Status: FUTURE — SIEM (S6 Wazuh) must be running first; AI layer is second
An AI-assisted security-operations layer that sits ABOVE the Wazuh SIEM, NOT part of it. Architecture:
Reference knowledge base (EVALUATE, do not install wholesale): GitHub mukul975/Anthropic-Cybersecurity-Skills (~17k stars) — NOTE: NOT Anthropic-affiliated; github.com/anthropics/cybersecurity-skills returns 404; the real anthropics/skills repo has no cyber content. This is an independent community project in the agentskills.io format (YAML frontmatter + Markdown + scripts/ + references/). Covers SOC/IR/threat-hunting/forensics/cloud mapped to MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF. Apache 2.0.
Supply-chain rule: Community scripts/ are UNTRUSTED — audit on S4 (dev) only, never run against S6/Wazuh or S3-live. Cherry-pick workflows that add value, rewrite into our own vetted atoms (same discipline as the PowerShell scripts library). Do NOT wholesale-install.
Also evaluate: Security-Phoenix-demo/security-skills-claude-code (MIT) — AppSec/DevSecOps-oriented rather than SIEM/SOC; different job but overlapping methodology.
Sequencing: Wazuh on S6 comes first (gated on sizing decision per id=25), AI layer second. See #23 for local-LLM architecture.
Status: Local LLM running on Simon's desktop — architecture agreed 19 Jun 2026
Simon's local LLM: gpt-oss:20b via Ollama (Ryzen 9 5950X, 96GB RAM, RTX 4070 Ti 12GB — loads ~11.3GB VRAM), fronted by Open WebUI at localhost. Runs in HYBRID with Claude+MCP as a two-tier AI stack.
Two-tier model:
Unlocked roadmap items (free local tier makes cost-parked layers viable sooner):
NexaOps selling point: "client data processed on your own infrastructure, never leaves it" — valid only if true + documented (which data goes local vs cloud, written policy). The local box becomes infrastructure Xzopia must secure and back up like any server node.
SAFETY BOUNDARY (non-negotiable): local model = read/summarise/draft/classify ONLY. NEVER autonomous actions on client systems. Actions stay human- or Claude-gated. The hybrid boundary IS the safety boundary.
Does NOT accelerate TRMM build: the TRMM migration (library, policies, agent deployment) stays Claude/CC — the local box is a run-the-business layer, not a build-the-platform layer.
Status: SHELVED — dev-phase trade-off. Revisit post-stabilisation.
Goal: Design a proper key-management approach across the MSP stack — rotation schedule, single-use/temp keys where feasible, and possibly Claude Code fetching credentials from Vaultwarden at runtime via the bw CLI (dedicated low-privilege service account, scoped to one collection, unlock secret handled carefully).
Current state (acceptable for now): API keys live in per-server .env files (chmod 600, owned by deploy user). Vaultwarden is the system-of-record. Claude Code reads keys server-side at runtime via SSH — never echoed, never committed.
Trade-off to honour: Must NOT become so complex that real-time access during an incident is impaired. Reliable access first, clever access second. A key belongs where the consuming process runs — MCP service keys on their server (S3 live / S4 dev); CC operational keys where CC reads them. Centralising all keys onto one box creates a single point of failure.
Specific tasks when revisited:
bw CLI runtime fetch — CC logs in to Vaultwarden with a scoped service-account unlock secret, fetches the target key, uses it in-memory, logs out. Avoids storing keys in .env entirely.