From 12 Weeks to 3 Days: How Jedi Hill Helped a Fintech Enterprise Automate Security Threat Modeling with AWS Bedrock

A mid-size fintech enterprise was drowning in manual security reviews. Jedi Hill built an AI-powered threat modeling platform on AWS Bedrock that cut cycle time by 96% — without compromising security rigor.

The Challenge

Our client, a mid-size fintech enterprise operating in the digital payments and banking sector, runs a cloud-native platform that processes millions of transactions every day. Every new product feature had to pass through a rigorous security threat modeling review before development could begin — a critical safeguard, but also a growing bottleneck.

The customer's 12-person security engineering team was manually reviewing every product requirements document (PRD) against the STRIDE threat modeling framework. As the engineering organization scaled, this manual process became unsustainable:

• 480 engineer-hours consumed per release cycle on manual threat analysis

• 12-week average delay between PRD completion and security-cleared development start

• Only ~40% of PRD sections could realistically be reviewed given team bandwidth

• A prior compliance audit had flagged 3 high-risk unaddressed threats directly attributable to review capacity constraints

The business impact was significant: missed quarterly release commitments, rising regulatory exposure under PCI-DSS Section 6.3.2, and a security team stretched thin on repetitive document analysis instead of high-value remediation work.

The customer needed to transform threat modeling from a manual, bandwidth-constrained process into an automated, consistent, and auditable one — without sacrificing the depth of analysis their compliance obligations required.

The Solution: An AI-Powered Threat Modeling Platform on AWS

Jedi Hill designed and delivered a production GenAI application built entirely on Amazon Bedrock, transforming the customer's threat modeling workflow from rule-based manual review into LLM-driven automated analysis.

How it works:

1. Ingestion — Engineers upload a PRD (PDF) through a web application. The document is parsed using a multi-backend pipeline (including docling and a custom-tuned pdfplumber engine) optimized for complex, multi-column, and bilingual (English/Chinese) technical documents.

2. AI-Powered Two-Step Analysis — Each PRD section is run through a two-step pipeline on Amazon Bedrock (using Claude models, with a pluggable provider layer for cost and latency tuning):

   • Step 1 — Pattern Matching: The model analyzes each section against a curated library of 26 threat patterns spanning STRIDE categories, business logic risks, and fintech-specific threats (e.g., loyalty fraud, KYC manipulation).

   • Step 2 — Threat Generation: A second Bedrock call uses the matched patterns as context to generate detailed, structured threat entries — including STRIDE classification, risk score, attack method, business impact, and mitigation guidance.

3. Bilingual Delivery — The finalized English threat report is translated into Chinese using Amazon Translate, ensuring consistency between languages without the risk of content drift from re-running the LLM twice.

4. Production Infrastructure — The entire platform runs on AWS ECS Fargate for the core API service, with AWS Lambda and AWS Step Functions orchestrating asynchronous analysis jobs for large documents. Infrastructure is fully codified in Terraform, with Amazon CloudWatch for monitoring and AWS Secrets Manager for credential management — all within a secure, multi-AZ VPC architecture.

Figure: Solution architecture — users authenticate and upload a PRD through the web interface; the file lands in Amazon S3, which triggers an AWS Lambda function to kick off an AWS Step Functions workflow. The workflow invokes an ECS Fargate-hosted service that calls Amazon Bedrock for AI-driven threat analysis and Amazon Translate for bilingual report generation, with job status tracked via a second Lambda and results written back for the user to review.

The result is an end-to-end pipeline where a security engineer uploads a PRD and receives a comprehensive, structured threat model in minutes rather than weeks — with full traceability back to the original document sections.

Core AWS services used: Amazon Bedrock, Amazon Translate, AWS ECS Fargate, AWS Lambda, AWS Step Functions, Amazon ECR, Amazon VPC, AWS IAM, AWS Secrets Manager, Amazon CloudWatch, and Terraform for infrastructure as code.

The Results

Since going into production, the platform has delivered measurable, sustained impact:

Metric	Before	After	Improvement
Threat modeling cycle time	12 weeks	3 days	96% reduction
Security engineering hours per release	480 hours	~38-40 hours	~92% reduction
PRD coverage	~40% of sections	100% of sections	2.5x increase
Mean time to identify critical threats	3 weeks	4 hours	~99% reduction

Beyond the headline numbers, the platform enabled the customer's security team to shift from repetitive manual document analysis to higher-value work: validating AI-generated findings, deepening architecture reviews, and strengthening remediation guidance — all while maintaining full audit traceability for regulatory compliance.

Lessons Learned

Building a production-grade GenAI application surfaced real engineering challenges worth sharing:

• PDF diversity is a moving target. Complex, mixed-language technical documents required iterative parser improvements — we evolved from a baseline parser at ~78% section-extraction accuracy to a tuned pipeline exceeding 96%, layering in a higher-quality (but more resource-intensive) parsing engine for the hardest documents.

• LLM output needs defensive engineering. Because large language models don't guarantee well-formed structured output, we built a multi-layer repair pipeline so that an isolated parsing failure affects a single threat entry rather than an entire analysis batch.

• Design async-first for LLM-heavy workloads. Larger documents exceeded synchronous request timeouts, which led us to move to an asynchronous, job-polling architecture backed by Step Functions from early on.

• Evaluation frameworks matter as much as the model. Our biggest takeaway: building a systematic evaluation harness — with human-reviewed ground truth and measured precision/recall — should happen alongside the first version of any GenAI pipeline, not be deferred until after launch.

About Jedi Hill

Jedi Hill is an AWS Partner specializing in generative AI consulting and cloud-native application delivery. We help enterprises move from manual, knowledge-intensive processes to scalable, AI-powered platforms built on AWS — combining deep AWS service expertise with production engineering rigor to deliver solutions that hold up under real-world compliance and operational demands.

Interested in how generative AI on AWS could transform your team's workflows? [Contact Jedi Hill] to learn more.

Notes for you before publishing (delete before posting)

1. Per the self-assessment materials, this customer is anonymized at their request — do not add the real company name anywhere in this post. If you'd like to name them, you'll need written customer sign-off first.

2. Replace [Contact Jedi Hill] with your actual contact/CTA link.

3. Once published, copy this page's live URL into the AWS Case Study Validation Request form's "Case Study URL" field, and select "blog post" as the URL Type.

4. Consider adding your architecture diagram (Customer_01_Architecture_Diagram.pdf content, redrawn/genericized) as an image in the post — AWS reviewers specifically look for the solution being "AWS-centric," and a visual reinforces that quickly.