Your AI-powered threat modeler just flagged 47 security issues in your new microservices architecture. Your team spends a week investigating the findings. Half of them don’t actually apply because your architecture documentation still describes the monolith you migrated away from six months ago. The rest are too vague to action because your diagram showed “data storage” instead of specifying S3 buckets, encryption settings, and access policies.

Sound familiar? You’ve just encountered the GIGO principle in action: Garbage In, Garbage Out.

The quality of your threat model is fundamentally limited by the quality of your architecture documentation. Feed a threat modeling tool incomplete, outdated, or vague information, and you’ll get incomplete, outdated, or vague security insights in return. No amount of sophisticated AI can compensate for poor inputs.

The GIGO Principle in Security

The GIGO principle — garbage in, garbage out — has been a foundational concept in computing since the 1960s. The principle is simple: systems process what you give them. If you input flawed data, you get flawed outputs. This applies universally, from statistical analysis to machine learning to threat modeling.

AI-powered tools actually amplify the GIGO problem rather than solving it. Modern language models excel at finding patterns, but those patterns are only as good as the data they’re analyzing. Feed Claude or GPT a vague architecture description, and it will generate plausible-sounding threats based on vague assumptions. Those threats might be technically correct in a general sense, but they won’t reflect the specific security posture of your actual system.

Think of it like cooking. You can be a Michelin-starred chef with perfect technique, but if your ingredients are rotten, the meal will be terrible. Similarly, even the most sophisticated threat modeling engine can’t compensate for rotten documentation.

Understanding why threat modelling matters starts with recognizing that the process is only as valuable as the foundation it’s built on. That foundation is your architecture documentation.

Common Documentation Pitfalls

We’ve analyzed hundreds of architecture documents submitted to ThreatKrew. In our experience, the majority of false positives in threat models trace back to incomplete or outdated documentation rather than flaws in the analysis itself. The garbage in, garbage out pattern is remarkably consistent. Certain pitfalls emerge repeatedly, each one undermining the quality of the resulting threat model.

Missing or Vague Data Flows

“We store user data in S3” tells us almost nothing from a security perspective. What kind of data? Which bucket? Is it encrypted at rest? With AWS-managed keys or customer-managed KMS keys? Who has access? What’s the lifecycle policy? Are versioning and MFA delete enabled?

Without specifics, a threat model has to make assumptions. It might flag generic S3 risks like public bucket exposure, but it can’t tell you whether your IAM policies follow least privilege or whether your encryption implementation meets compliance requirements.

Unclear Trust Boundaries

We see diagrams all the time with boxes labeled “Frontend,” “API,” and “Database” connected by arrows. But where are the trust boundaries? Which components are internet-facing versus internal-only? What authentication is required to cross each boundary? Which networks can communicate with which?

Trust boundaries define your attack surface. Without clear boundaries, a threat model can’t accurately identify where attackers might gain initial access or how they might move laterally through your system.

Outdated Architecture Descriptions

Architecture evolves constantly. You refactor. You migrate to new services. You add features. But documentation often lags behind by months or quarters.

When your threat model is based on documentation from last year, it’s modeling a system that no longer exists. The threats it identifies might be irrelevant, while the real risks in your current architecture go undetected. This is particularly dangerous because it creates a false sense of security.

Missing Cloud Configuration Details

Cloud infrastructure security lives in the details: IAM policies, security group rules, KMS encryption settings, Lambda execution roles, DynamoDB encryption, VPC configurations. These details determine your actual security posture.

A diagram showing “Lambda function calls DynamoDB” doesn’t tell us whether that Lambda has overly permissive IAM policies, whether the DynamoDB table is encrypted, whether VPC endpoints are used, or whether CloudTrail logging is enabled. Those configuration details are where most cloud security issues hide.

Unstated Assumptions

“All our APIs require authentication” is a common statement in architecture docs. But how? API keys? JWT tokens? OAuth 2.0? Cognito? IAM SigV4? Are there rate limits? Is MFA required for sensitive operations? What happens if a token is compromised?

Assumptions without implementation details create blind spots. The threat model might assume strong authentication when reality is a single shared API key rotated annually.

As we explore in threat modelling is a conversation, security analysis requires dialogue about these assumptions. When they’re unstated in documentation, that conversation can’t happen effectively. Different threat modelling methodologies handle assumptions differently, but all require them to be explicit.

The Real Cost of Bad Documentation

Poor documentation doesn’t just produce mediocre threat models. It creates cascading problems that undermine your security program.

False negatives are the most dangerous outcome. When critical architecture details are missing, real threats slip through undetected. That exposed admin endpoint you forgot to document? Not in the threat model. The overly permissive IAM role you neglected to mention? Missing from the analysis. These gaps in documentation become gaps in your security.

False positives waste engineering time and erode trust. When documentation is vague or outdated, threat models flag issues that don’t actually exist in your current system. Teams investigate these phantom threats, realize they’re not applicable, and start questioning the value of the entire threat modeling process. Alert fatigue sets in.

Wasted effort compounds across your organization. Security teams spend hours triaging false positives. Engineering teams spend days implementing remediations for threats that don’t apply. Leadership makes risk decisions based on incomplete information. All because the input documentation was flawed.

Compliance risk emerges when auditors ask to see your threat model documentation. If your threat model is based on outdated or incomplete architecture information, you can’t demonstrate that you’ve actually assessed the risks in your current system. This can be a compliance failure even if your actual security controls are strong.

Eroded trust might be the worst long-term cost. When threat modeling consistently produces poor results because of documentation issues, teams lose confidence in the process. Security becomes seen as a checkbox exercise rather than a valuable engineering practice. This makes it harder to build security into your culture.

As we discuss in why it’s never too early for security, establishing good practices from the start prevents these compounding costs. Good documentation habits are one of those foundational practices.

What Good Documentation Looks Like

So what does threat-model-ready architecture documentation actually contain? Here’s a practical checklist:

Clear architecture diagram with directional data flows showing exactly what communicates with what, and trust boundaries clearly marked with justification for where each boundary is placed. Label which components are internet-facing, which are internal-only, and which cross organizational boundaries.

Data inventory cataloging what data exists where, including classification (PII, financial, public), encryption status (at rest and in transit), access controls (who can read/write), retention policies, and backup procedures.

Technology stack with security-relevant configuration details. Not just “we use Lambda” but specifics about execution roles, VPC settings, environment variables, layers, and logging. Not just “we use RDS” but engine version, encryption settings, backup configuration, and network isolation details.

Explicit trust boundaries with justification. Why is this the boundary? What authentication and authorization is required to cross it? What happens if those controls fail?

Current security controls baseline documenting what’s already in place. WAF rules, GuardDuty findings response, CloudTrail monitoring, security group configurations, KMS key policies. This prevents threat models from flagging issues you’ve already addressed.

Documented assumptions with specifics. Instead of “all data is encrypted,” specify “all S3 buckets use AES-256 encryption with AWS-managed keys except [specific buckets] which use customer-managed KMS keys for compliance reasons.”

Change log with dated updates so reviewers can see when documentation was last verified as accurate. This doesn’t need to be elaborate. Even “Last verified: 2026-02-01” helps establish recency.

Multi-format support combining architecture diagrams, prose descriptions, and infrastructure-as-code. Each format captures different details. Diagrams show flows, prose explains business context and assumptions, IaC reveals actual configuration.

How ThreatKrew Helps

We built ThreatKrew after seeing this pattern repeatedly with customers. Smart security teams using sophisticated tools, but getting mediocre results because their architecture documentation had gaps.

Our Clarify feature addresses this directly. When you submit architecture documentation, Clarify analyzes it and generates targeted questions about gaps and ambiguities:

“You mention S3 buckets for user uploads but don’t specify encryption settings. Are you using AWS-managed keys or customer-managed KMS keys?”

“Your diagram shows Lambda invoking DynamoDB, but the execution role permissions aren’t documented. Does this Lambda have least-privilege access or broader permissions?”

“You describe API authentication but don’t specify the mechanism. Are you using API keys, JWT tokens, or IAM authorization?”

These aren’t generic security questions. They’re specific to what’s missing or unclear in your documentation. Clarify flags missing data flows, unstated assumptions, and configuration gaps before generating the threat model.

The result is better inputs, which produce more accurate threat identification and fewer false positives. Teams spend less time investigating phantom issues and more time addressing real risks.

We also generate documentation improvement recommendations as part of the threat modeling output. These suggestions help you enhance your architecture documentation for future threat models, creating a virtuous cycle of improvement.

Better documentation inputs lead to more accurate threat models, which surface real security improvements, which get implemented and documented, which enables even better future threat models.

AI Augments, It Doesn’t Replace

It’s crucial to understand what ThreatKrew is and isn’t. We’re not replacing threat modelers or security architects. We’re augmenting their expertise with AI-powered analysis.

ThreatKrew processes your architecture documentation and generates threat models based on established frameworks like STRIDE and MITRE ATT&CK. But humans remain the decision-makers in the process. Threat modelers review outputs for reasonableness. Security architects decide which threats are acceptable risks and which require remediation.

Business context matters enormously. A particular threat might be accepted risk for a startup focused on speed to market, but completely unacceptable for a bank handling financial transactions. No AI can make that judgment call. Only humans with business context can.

The loop works like this: Humans define the problem by documenting architecture. AI helps solve it by systematically analyzing that architecture for security issues. Humans decide what to do by prioritizing remediation based on business risk.

Use Clarify to improve your documentation quality, not to skip documentation entirely. The goal is better inputs that enable better AI-assisted analysis, which supports better human decision-making.

Start With Better Documentation

The GIGO principle applies to threat modeling just as it does to any data-dependent process: documentation quality determines threat model quality, which determines your security posture.

If you want better threat models, start by auditing your architecture documentation. Use the checklist above. Look for vague statements, missing configuration details, unclear trust boundaries, and unstated assumptions. Ask yourself whether a security expert who’s never seen your system could understand the attack surface from your documentation alone.

Improving documentation takes time, but it pays dividends across your security program. Better threat models. Fewer false positives. More accurate risk assessments. Stronger compliance posture. Greater team confidence in the security process.

Remember: you can’t cook a great meal with rotten ingredients, and you can’t build a strong security posture on weak documentation.

The next time you run a threat model and get disappointing results, don’t blame the tool. Check the inputs first. More often than not, that’s where the problem lies.

Want to dive deeper? Learn about why threat modelling matters, understand threat modelling as a conversation, or explore how we built ThreatKrew.

Ready to improve your threat models? See the product or join the Founders Program to help shape the future of automated threat modeling.

Garbage In, Garbage Out: Why Documentation Quality Makes or Breaks Your Threat Model