Adaptive Phishing Campaign Simulation Engine

How the system actually runs.

Each stage below is a real component in the deployed pipeline. Stages outlined in teal are control points: the places where the architecture constrains what the model can receive or emit.

What it runs on.

How it is wired.

1. Cloud-native on AWS with no on-premises footprint.
2. The per-target profile is built from HR API data, covering role, department, and context themes, combined with historical engagement data from prior campaigns.
3. The primary Bedrock call generates a phishing email tailored to that individual profile.
4. A secondary Bedrock call with a separate reviewer system prompt checks the generated email against authorized scope before the email is queued for delivery.
5. Engagement data, meaning click rate, report rate, and response pattern, feeds back into the profile after each cycle. The system adapts its vulnerability-vector focus over time.
6. Every generated email and its associated prompt are written to the audit log before any downstream action proceeds.

What keeps it inside its contract.

Guardrails were designed in from the start, not added after the fact. Where the system touches untrusted input, a control sits between that input and the model.

• The system prompt is versioned and audited. It carries explicit hard limits, including no real external organizations, meaning no fake Microsoft or IRS lures, and no harassment-adjacent content.
• Client engagement letter scope terms are stored as a data tag on the account record. Orchestration validates the tag before allowing generation to proceed.
• HR profile data is treated as untrusted input. A separate schema-extraction call converts raw HR text into a typed profile object before it reaches the generation prompt, which closes off prompt injection through employee-controlled fields such as job title.
• A second Claude endpoint with a dedicated safety-check persona independently evaluates every generated email before it is queued for delivery.
• An acceptable-use agreement is required from all clients, logged and cryptographically associated with every campaign run.
• Red-team exercises specifically tested injection through HR data fields, including a case where a malicious employee injected instruction text into their own job title field.

What we still track.

No production AI system is finished. These are the live risks carried by this architecture, documented for the operating team rather than buried.

• Generative output is inherently variable. Edge-case emails could slip past the secondary reviewer and carry unintended content without periodic human spot-checking.
• Employees who correctly identify and report a simulation may share it internally, reducing effectiveness across a cohort in that cycle.
• HR data staleness, from role changes or departures, could produce simulations irrelevant to the current role or aimed at the wrong person.
• Client misuse risk. A client could attempt to repurpose the platform for real phishing campaigns outside the authorized simulation scope.

What changed.

• Simulation click rates dropped faster per user cohort than static-template baselines, which indicates the adaptive personalization was reaching genuinely susceptible vectors.
• Security behavior change, measured by report rate, increased meaningfully over multiple adaptive cycles per user.
• The dual-Claude architecture, generator plus reviewer, established an auditable safety pattern for generative content pipelines carrying compliance obligations.
• The versioned, auditable system prompt gave the MSSP a defensible paper trail for any client dispute about generated campaign content.

On numbers. Client identity and any identifying detail are withheld under NDA. Outcomes are stated as direction and materiality rather than as figures we are not free to publish.