Threat Model First: Security as the Architecture's Source.

You're designing the security architecture for a new merchant payment feature at a Botswana mobile money platform — 50,000 wallet users, Bank of Botswana audit in eight weeks. The threat model is the engagement's first deliverable; every architectural decision flows from it. You also write an AI-tool security policy for the compliance officer, because the development team uses AI with database connections and no existing framework covers that surface.

The discipline skills: constructing a threat model with STRIDE per trust boundary and OWASP Top 10 as vocabulary; deriving controls from named threats; running a posture review against AI's default-open patterns; reasoning about prompt injection through MCP-connected data; designing fail-closed exception paths and verifying them under failure injection; writing three deliverables for three audiences.

The AI-direction lesson: AI's security defaults are a pattern, not a sequence of mistakes — permissive CORS, optimistic input trust, skipped authorisation, fail-open exceptions, no audit writes. You name the pattern, harden against it systematically, then partition a separate session under an attacker framing to attack what AI just built. Contamination across sessions is the directing failure you design against.

Your Role

You're the security architect and builder. You construct the threat model, derive the architecture, scaffold and harden a small but real implementation, run the AI-specific review, and ship three artifacts into a live financial system regulated by the central bank.

No deliverable templates remain. The platform supplies the governance file, the email chain, two sparse domain references, an OWASP-as-design-tool reference, a threat-model skeleton (structure only), an AI-tool policy form reference (vocabulary only), and a runnable scaffold with empty controls. The architecture, controls, deliverable structures, trade-off log, test architecture, and deployment decision register are your design.

AI does the legwork on every layer that is not the analytic call. It enumerates threats; you name which are load-bearing. It scaffolds; you harden. It runs the adversarial review under a framing you design; you name which exploit paths are real. Four partitioned sessions with opposed framings — and you enforce the partition.

What's New

Last time, on the Vava'u marine-conservation comparative-analysis engagement for Mele, you carried the work to two written deliverables — partitioning two stack contexts, refusing AI's "bigger rebuild" defaults, producing judgment, not a running system. This project returns to building, with the threat model driving every layer.

The threat model precedes the architecture. Before, security joined other disciplines on equal footing — added to an architecture already taking shape. Now every boundary, control, exception path, and audit entry traces to a named threat.

Four partitioned sessions, one of them adversarial. Last time, two stack contexts. This time, four — threat-model, architecture, implementation, adversarial-review — with opposed framings. Contamination softens attack scenarios into "minor improvements." You design against it.

AI as an attack surface, named directly. The development team uses AI tools with MCP connections to the database. A merchant could register with a crafted business name that an AI assistant reads through that connection. The policy you write for the compliance officer is load-bearing because no existing framework covers it.

Tools

• Claude Code with four partitioned project sessions: threat-model (analytic), architecture (constructive), implementation (collaborative), adversarial-review (attacker framing in its own CLAUDE.md).
• Node.js 20 + Express 4 for the merchant payment service. PostgreSQL 15 for the data. Redis 7 for the rate-limit store.
• Docker Compose for the local Postgres and Redis containers.
• Semgrep with custom rules you author from the threat model. OSV-Scanner for dependencies. Stryker for mutation testing against the authorisation and audit-log writer modules.
• Git and GitHub. A new kgotla-merchant-payments repo.
• VS Code + Claude Code extension.

Materials

• The forwarded email chain (kagiso-email-chain.md) — first contact. The CTO forwards a compliance officer's note and adds his framing. Three hidden constraints and two blind spots surface only when you ask.
• The engagement governance file (CLAUDE.md) — five named trust boundaries, verification targets, the four-session partition discipline, commit conventions.
• Two sparse domain references (references/merchant-payment-domain.md, references/kgotla-platform-reference.md) — Botswana's mobile-money ecosystem; the existing platform at entity level.
• An OWASP-as-design-tool reference (references/owasp-top-10-as-design-tool.md) — each category as a design constraint, with a design question and a test-claim line.
• The threat-model skeleton (templates/threat-model-skeleton.md) — STRIDE-by-trust-boundary with OWASP prompts. Headers and prompts only; no example threats.
• An AI-tool policy form reference (templates/ai-tool-policy-form-reference.md) — what such a policy contains and who reads it.
• A runnable starter scaffold (merchant-payment-service/) — Docker Compose, project structure, schema, Redis client, audit-writer stub, local mock audit server. Empty routes, empty auth, empty tests.
• Security tool configurations (semgrep-rules/, security-tools/) — Semgrep with an empty custom-rules section you author from the threat model; OSV-Scanner and Stryker pre-configured.

The brief is the email and the question the CTO asks.