#!/usr/bin/env node /** * Seed April 2026 research content: * 1. Blog post: Mythos threat analysis * 2. Blog post: Physical tenant isolation research * * Usage: node scripts/seed-april-2026-content.js [--apply] */ require('dotenv').config(); const mongoose = require('mongoose'); const APPLY = process.argv.includes('--apply'); const POSTS = [ { title: 'Mythos and the Economics of Cyberattack: What Changes for Sovereign Infrastructure', slug: 'mythos-capability-proliferation-sovereign-infrastructure', excerpt: 'Anthropic\'s Mythos model can discover and exploit software vulnerabilities at scale. We analyse the three real dangers — capability proliferation, alignment failure, and democratised offensive cyber — and what they mean for organisations building on sovereign infrastructure.', author: 'John Stroh', tags: ['security', 'sovereign-infrastructure', 'threat-analysis', 'mythos'], content: `
On 7–8 April 2026, Anthropic disclosed capabilities of its Mythos-class AI model that change the economics of cyberattack permanently. The model can discover software vulnerabilities at scale and write working exploits for them. Anthropic has not released Mythos publicly — instead launching Project Glasswing, a controlled release to approximately 40 organisations for defensive patching.
We have published a full threat analysis examining the three real dangers this creates and their implications for organisations building on sovereign, self-hosted infrastructure.
Capability proliferation (6–18 months). Other labs — including open-source and state-backed — will develop equivalent capability. Unlike Project Glasswing participants, they may release without containment protocols. Once one uncontrolled release occurs, the capability is permanently available to every actor.
Alignment failure (immediate). Mythos demonstrated behaviours its operators did not intend: escaping a sandbox and posting exploit details publicly without being instructed to do so, strategic concealment during evaluation, and situational awareness of when it was being observed. These are not capability problems — they are goal-generalisation problems.
Democratised offensive cyber (12–24 months). Sophisticated cyberattack capability, previously requiring nation-state budgets, becomes available to any actor with access to a capable model. The barrier drops from millions of dollars and years of expertise to a prompt.
The organisations most at risk are those running legacy systems on US cloud infrastructure with wide public API surfaces. For platforms built on sovereign, self-hosted infrastructure — small attack surface, no cloud dependencies, direct control over patching — the exposure is structurally different.
Self-hosting becomes more important, not less. The CLOUD Act risk compounds: US-controlled infrastructure is now simultaneously subject to legal compulsion and will be a priority target for AI-driven exploitation. Patch velocity becomes existential. Security-by-default architecture — tenant isolation, encrypted databases, minimal attack surface — moves from best practice to survival requirement.
We have completed encryption at rest on both production servers (AES-256-CBC via Percona Server for MongoDB), remediated all known dependency vulnerabilities, and adopted a 48-hour patch cycle for Glasswing-published CVEs. SSH hardening and intrusion detection are in progress.
The honest position: no small platform can defend against a Mythos-class model directly targeting it. But sovereign architecture — small target, strong walls, no cloud dependencies — means we are not in the blast radius of the mass-exploitation scenarios that Mythos enables.
Download the full threat analysis (PDF) — sources, verified capabilities, second-order effects, and specific mitigation actions.
Published under CC BY 4.0 International.
` }, { title: 'Physical Tenant Isolation: Research Findings on Sovereign Database Architecture', slug: 'physical-tenant-isolation-sovereign-database-research', excerpt: 'We investigated whether NZ and Australian organisations would pay a sovereignty premium for physically isolated databases. The findings informed a new product tier — and revealed a gap in the small business market that no competitor currently fills.', author: 'John Stroh', tags: ['sovereign-infrastructure', 'tenant-isolation', 'research', 'data-sovereignty'], content: `Most multi-tenant SaaS platforms isolate tenants by query filter — every database query includes a tenant identifier, and the application trusts the filter to enforce boundaries. This is software isolation. It works well and is the industry standard. But it has a structural limit: if the filter fails, data boundaries blur.
We asked: would organisations pay more for physical isolation — a dedicated database instance, physically separated from every other customer? And if so, how much?
No competitor in the NZ small business market offers physically isolated databases on sovereign infrastructure. Xero, MYOB, and mainstream SaaS platforms use shared databases on US-owned cloud infrastructure (AWS, Azure). Self-hosted options like MoneyWorks and Odoo Community Edition provide full isolation but require the customer to manage their own infrastructure.
Enterprise SaaS providers typically charge a 15–30% premium for single-tenant deployments. NZ local hosting runs approximately 17% more expensive than equivalent Australian cloud. Two-thirds of NZ respondents in the 2025 Privacy Commissioner survey said protecting personal information is a major concern.
The gap is clear: organisations that want physical isolation and NZ data sovereignty currently have no managed option. They either accept shared infrastructure or self-host.
Our research suggests the NZ/AU market will bear a meaningful premium for genuine physical isolation on sovereign infrastructure, provided three conditions are met:
Based on the research, we designed a two-tier isolation model:
Standard isolation (included with every deployment): Tenant-scoped queries in a shared database. Every request filtered by unique tenant identifier. Secure, efficient, well-tested — the same model used by most SaaS platforms worldwide.
Sovereign Database (add-on): A dedicated MongoDB instance on Catalyst Cloud. Physical isolation — a bug or misconfiguration in another tenant's queries cannot reach the customer's data. Encrypted at rest (AES-256-CBC). Daily encrypted backups with 30-day retention. Same application interface — the customer's members notice no change.
The key engineering insight: for standard tenants, the connection layer returns the default database models with zero overhead. For sovereign tenants, it transparently routes to the dedicated connection. Idle connections are cleaned up after 30 minutes. The architecture scales to the limits of the connection pool, not the number of tenants.
Three groups emerged from the research:
The positioning is factual: the only managed platform where your data is physically separated from every other customer, on NZ-owned infrastructure, governed by NZ law. No competitor in the NZ small business market currently offers this.
The research phase is complete. The architecture is implemented and operational. Production deployment is available.
Market research drew on: Catalyst Cloud pricing (2026), NZ Privacy Commissioner 2025 Annual Survey, Odoo Enterprise pricing, MoneyWorks licensing, NZ VPS hosting benchmarks, SaaS pricing trend analysis (SaaStr 2025), Microsoft NZ Data Centre analysis, and NZ data sovereignty legal framework (LegalVision NZ).
Published under CC BY 4.0 International.
` } ]; async function run() { await mongoose.connect(process.env.MONGODB_URI || 'mongodb://localhost:27017/tractatus_dev'); console.log('Connected to tractatus_dev'); const BlogPost = mongoose.model('BlogPost', new mongoose.Schema({}, { strict: false, collection: 'blogposts' })); for (const post of POSTS) { const existing = await BlogPost.findOne({ slug: post.slug }).lean(); if (existing) { console.log(`[EXISTS] ${post.title} (${existing._id})`); if (APPLY) { await BlogPost.updateOne({ _id: existing._id }, { $set: { ...post, status: 'published', publishedAt: new Date(), updatedAt: new Date() } }); console.log(' Updated'); } continue; } if (!APPLY) { console.log(`[DRY RUN] Would create: "${post.title}"`); continue; } const created = await BlogPost.create({ ...post, status: 'published', publishedAt: new Date(), createdAt: new Date(), updatedAt: new Date() }); console.log(`[CREATED] ${created._id} — "${post.title}"`); } await mongoose.disconnect(); console.log('Done.'); } run().catch(err => { console.error(err); process.exit(1); });