You're running a full security engagement for Pacific Islands Development Bank in Port Vila, Vanuatu, where the CEO needs an assessment of not just the bank's systems but every organization the bank trusts.
The discipline skills: scoping a forward engagement from a meeting transcript with no template; mapping the trust boundaries between connected organizations and treating those boundaries as the unit of analysis; profiling a different adversary per entity and prioritizing reconnaissance under a hard four-month deadline; running a cross-boundary exploitation campaign across five-plus interconnected entities; designing detection and remediation a resource-constrained bank can actually run; and writing one report that moves three audiences — the board, the internal IT team, and an external funding review — through three different arguments at once.
The AI-direction lesson: you've directed AI through single engagements before. Here the engagement is too large for any AI session to hold. AI executes every step — reconnaissance, exploitation, rule drafting, report sections — but it loses which of five-plus entities a finding belongs to, which path it abandoned, and which entity it already assessed. It optimizes detection for broad coverage instead of this bank's actual threat model. When a request to look at a system the bank doesn't own arrives mid-engagement, AI treats it as work to start now. You are the only continuity mechanism. The engagement stays coherent because you hold it, not because AI does.
Your Role
You're the engagement lead. You scope the work, map where one organization's trust ends and another's begins, run the campaign forward across the chain, decide what to defer and what to decline, and deliver an assessment that satisfies a board, a technical team, and a donor's funding review simultaneously.
Last time you inherited a half-built setup and verified it backward. This time nothing is inherited. You design the entire engagement forward from a meeting transcript, the way you did once before — but the subject is no longer one system. It's a network of organizations that trust each other, and the dangerous ground is the boundary between them, not inside any one of them. AI is an executor that cannot hold the engagement. No colleague review is staged at any point — a senior colleague is reachable on-demand but won't volunteer. The judgment in the room is yours.
What's New
Last time you audited an inherited Wazuh stack at a Baghdad university — partly wrong, almost entirely undocumented, with no key telling you what to trust.
This time you build forward again, but across organizations. The bank's internal systems can be sound and the bank can still be compromised through a vendor it trusts, a branch sync with no integrity check, or a donor connection that accepts unencrypted data. The engagement is plural — a bank, a mobile-banking vendor, donor portals, and island branches that lose connectivity for weeks.
The hard part: the client can only speak for one entity. He doesn't see the cross-organizational risks as security concerns until you frame them. Several entities are reachable only through contracts you can't accelerate, so you have to decide where not to look. A request arrives mid-engagement that is genuinely out of scope and still a trust boundary you must account for. No template, no answer key, no colleague. This is the dress rehearsal for working alone.
Tools
- Claude Code — familiar. You author the engagement-memory
CLAUDE.mdand design the offensive, defensive, and reporting contexts upfront, because no single AI session can carry this engagement. - The purple-team toolkit — familiar reconnaissance, exploitation, and replay tooling, run across multiple entities.
- A resource-constrained SIEM/log stack — the Wazuh, Loki, and Grafana family is the production architecture Unit 6 designs for (a bank with branches that lose power and connectivity); the lab does not bundle a runnable SIEM substrate, so the rule-placement, threat-model alignment, and resource-sizing work in Unit 6 reads symbolically against the multi-entity Docker fixtures' log behaviour (logging.info stdout + the Unit 4 injection payloads). A production deployment of the designed architecture is the implementation handoff.
- Sigma — familiar. Detection-as-code, aligned to this engagement's multi-entity threat model rather than to coverage completeness.
- git/GitHub — for the scope, the trust-boundary map, the campaign records, and the deliverable.
No new tool installation is introduced; any entity-specific service arrives as a material.
Materials
- The introductory call — the meeting transcript, delivered in chat. Symptoms and scope ambition only — not a brief.
- The multi-entity environment (
multi-entity-environment/) — the lab standing the bank's core banking system, the third-party mobile-banking platform, the donor portals connecting to five external endpoints with mixed encryption, and the branch-connectivity simulation including the offline batch-sync path. Not a single target. - Bank context (
bank-context.md) — the operational reference: Vanuatu Vatu, six island branches, the four-month funding-review timeline, the donor partners, and the real resource constraints. - Project governance (
CLAUDE.md) — project context and verification targets.
There is no engagement methodology, scope document, threat model, trust-boundary map, detection strategy, remediation program, or report. There is no answer key for which entities or boundaries are weak, and no staged colleague review at any point. All of it is yours to produce.