MMASA: Multi-Model Adversarial Security Assessment

A reproducible framework for security verification using multiple AI models as adversarial reviewers, plus systematic model-level stress testing for exhaustive architectural analysis, plus structured upstream tracing for severity triage.

Overview

MMASA provides the first empirical demonstration that cross-provider AI auditing identifies 2.5x more security issues than any single-model assessment. The methodology applies Reason's Swiss cheese model to AI code review: by using models from different providers with misaligned failure modes, vulnerabilities that slip through one model's analysis are caught by another.

Version 3.1 added Adversarial Model Stress Testing (AMST), a systematic methodology for exhaustive security analysis of entire application architectures.

Version 4.0 adds Upstream Reachability Verification (URV), a triage technique applied to every finding from the prior four techniques. URV traces upstream callers and parallel paths to determine actual severity (active vs latent) and to surface adjacent bugs the original audit missed.

Key Contributions:

• Three-cycle assessment methodology (Pattern Scan, Attack Surface, Architecture Review, Reconciliation)
• Adversarial Model Stress Testing (AMST), exhaustive model enumeration + domain-grouped adversarial analysis
• NEW in V4.0: Upstream Reachability Verification (URV) for severity triage and adjacent-bug discovery
• First published taxonomy of 39 AI security auditing blind spots across 11 failure mechanisms (expanded from 36 in V3.1)
• AMST-7 adversarial question framework for structured attack thinking
• NEW in V4.0: Five-technique security stack integrating preventive, detective, architectural, and triage assessment
• Empirical results: 60+ findings across multiple assessment campaigns, plus a documented case study where URV inverted the severity ranking and surfaced three previously unflagged active bugs
• CI guard patterns for automated regression prevention

The Five-Technique Security Stack

MMASA V4.0 defines a layered security methodology where each technique covers vulnerability classes the others miss. Technique 5 (URV) is structurally different from Techniques 1 to 4: it does not find bugs from scratch, it triages findings from the others.

+------------------------------------------------------------+
|             MMASA SECURITY METHODOLOGY V4.0                 |
+------------------------------------------------------------+
|                                                            |
|  TECHNIQUE 1: SAFE IMPLEMENTATION FRAMEWORK (SIF)          |
|  +-- When: Every code change (pre-implementation)          |
|  +-- How: Gate system with adversarial questions           |
|  +-- Finds: Known vulnerability patterns in new code       |
|  +-- Gap: Only examines what's being changed               |
|                                                            |
|  TECHNIQUE 2: THREE-CYCLE MULTI-MODEL REVIEW               |
|  +-- When: Every code change (post-implementation)         |
|  +-- How: Model A, Model B, Model A adversarial pipeline   |
|  +-- Finds: Provider-specific blind spots (2.5x improve)   |
|  +-- Gap: Reviews diffs, not full architecture             |
|                                                            |
|  TECHNIQUE 3: ADVERSARIAL MODEL STRESS TEST (AMST)         |
|  +-- When: Milestone checkpoints (pre-launch, quarterly)   |
|  +-- How: Exhaustive enumeration + domain-grouped review   |
|  +-- Finds: Interaction bugs, temporal gaps, missing code  |
|  +-- Gap: No runtime verification                          |
|                                                            |
|  TECHNIQUE 4: AUTOMATED SCANNING (CI/CD)                   |
|  +-- When: Every commit (automated)                        |
|  +-- How: SAST tools, custom rules, regression guards      |
|  +-- Finds: Known patterns, regressions                    |
|  +-- Gap: No context, no interaction analysis              |
|                                                            |
|  TECHNIQUE 5: UPSTREAM REACHABILITY VERIFICATION (URV) NEW |
|  +-- When: After every finding from techniques 1-4         |
|  +-- How: Trace upstream callers + parallel paths          |
|  +-- Finds: True severity, blast radius, adjacent bugs     |
|  +-- Gap: Does not find new bugs; triages existing ones    |
|                                                            |
+------------------------------------------------------------+

Quick Start

Three-Cycle Review (per-change)

1. Select independent models from at least two different providers (e.g., Anthropic Claude + OpenAI GPT)
2. Provide full codebase context to each model
3. Execute passes sequentially with escalating abstraction
4. Reconcile independently, verify every finding against the actual codebase
5. Apply URV to every finding (V4.0), determine actual severity and surface adjacent bugs
6. Generate CI guards from confirmed findings
7. Document blind spots, analyze what each model missed

AMST Review (milestone checkpoints)

1. Enumerate all models in the system (filesystem, not documentation)
2. Group into domains by association and access path (8-15 models per group)
3. Apply AMST-7 questions to each model in each domain group
4. Apply URV to every flagged finding (V4.0), triage severity through wiring trace
5. Cross-reference findings across domains for interaction vulnerabilities
6. Synthesize and prioritize by impact, fix effort, and URV-corrected severity
7. Update blind spot taxonomy with newly discovered categories

URV Triage (per-finding): NEW in V4.0

After any finding from Techniques 1 to 4:

1. Identify the suspect file and line
2. Trace direct callers via grep
3. Trace callers' callers at least two to three hops upstream
4. Identify entry points (controllers, jobs, agent tools, webhooks)
5. Verify wiring at the entry point (route registered? YAML config? cron schedule?)
6. Look for parallel paths with the same shape but different wiring status
7. Reclassify severity: Active (wired), Latent (broken but unreachable), Adjacent (parallel sibling)

See the full documentation:

• docs/methodology.md, Three-cycle review framework
• docs/methodology_v4_addendum.md, V4.0 Section 3.5 (URV integration)
• docs/amst.md, Adversarial Model Stress Testing methodology
• docs/urv.md, NEW, Upstream Reachability Verification methodology
• docs/blind-spots.md, Complete 39-item blind spot taxonomy
• docs/coverage-matrix.md, Technique coverage comparison

The Blind Spot Taxonomy (V4.0, 39 Items)

Category	Count	Core Failure	Source
Existence vs. Reality	4	Assuming described code actually exists/functions	V1.0
Default & Inference	4	Security depending on implicit behavior	V1.0
Association & Scope	4	ORM associations including unintended records	V1.0
Pipeline & Process	5	Split paths or incomplete coverage	V1.0
Output & Export	4	Data export vulnerabilities	V1.0
Schema & Complexity	4	Documents ≠ schema, subsystem complexity	V2.0
Test Execution	4	Tests exist ≠ tests run, wrong framework	V2.0
Temporal & State	3	Expiration gaps, state cascade absence	V3.0 (AMST)
Interaction & Scale	2	Combinatorial exhaustion, cross-domain effects	V3.0 (AMST)
Absence & Staleness	2	Inverse existence gaps, config staleness	V3.1 (AMST-7)
Reachability & Wiring	3	Severity misclassification through file-only inspection	V4.0 (URV)

The AMST-7 Adversarial Questions

When stress-testing each model in a system, ask:

#	Question	What It Catches
1	What if this action is triggered twice?	Race conditions, double-spend, idempotency gaps
2	What if this is accessed from outside its intended scope?	Cross-tenant, wrong role, wrong state
3	What if a prerequisite is removed after this record exists?	State cascade failures, orphaned records
4	Are immutability and uniqueness enforced at the database level?	Soft guards, bypassable readonly methods
5	What happens when time-sensitive data expires?	Consent expiration, token reuse, stale cache
6	Do callbacks fail gracefully?	Side effect chains, async race conditions
7	What if an optional association is nil?	Missing context, nil comparison bypasses

The URV Seven Steps (NEW in V4.0)

When triaging any finding from Techniques 1 to 4:

#	Step	Purpose
1	Identify the suspect file and line	Capture precise location from prior technique
2	Trace direct callers	Grep for every invocation of the suspect symbol
3	Trace callers' callers (2-3 hops minimum)	Reach an actual entry point, not a midpoint
4	Identify entry points	Route, scheduled job, agent tool, webhook
5	Verify wiring at the entry point	Is the entry point actually exposed?
6	Look for parallel paths	Other files with same shape, different wiring
7	Reclassify severity	Active, Latent, or Adjacent

Coverage Matrix

Vulnerability Class	SIF	Three-Cycle	AMST	CI Scanning	URV
Auth bypass	✅	✅	✅	✅	n/a
Unscoped queries	✅	✅	✅	✅	n/a
Sensitive data in logs	✅	✅	✅	✅	n/a
Race conditions	✅	Partial	✅	❌	n/a
Consent/authz bypass	✅	✅	✅	❌	n/a
Temporal expiration gaps	❌	❌	✅	❌	n/a
Cross-domain interaction	❌	❌	✅	❌	n/a
Missing code (should exist)	Partial	❌	✅	❌	n/a
State cascade failures	❌	❌	✅	❌	n/a
Combinatorial identity	❌	❌	✅	❌	n/a
Severity misclassification	❌	❌	❌	❌	✅
Adjacent-bug discovery	❌	❌	❌	❌	✅
Multi-hop reachability	❌	❌	Partial	❌	✅

URV's unique contribution is in the bottom three rows, vulnerability classes that no other technique reliably catches.

Empirical Results

Three-Cycle Review (V1.0-V2.0)

• 35 findings across 7 commits
• 85+ files modified
• 2,000+ tests, zero regressions
• 2.5x improvement over single-model assessment

AMST (V3.1)

• 26 findings across 19 domain-grouped rounds
• 6 critical issues missed by three prior independent audits
• 400+ data models analyzed in approximately 4 hours
• 5 new blind spot categories discovered

URV Discovery Audit (V4.0, June 2026)

• 1 starting finding from Three-Cycle Review
• 3 previously unflagged active bugs surfaced via parallel-path enumeration
• 1 severity inversion (the original Critical/Active finding reclassified as Latent)
• 3 new blind spot entries documented (Category 11: Reachability & Wiring)
• Full case study in urv.md Section 3

Combined Detection (Three-Cycle + AMST + URV)

Finding Type	Three-Cycle	AMST	URV	Both/All
Pattern-based (auth, scoping, PII)	✅	✅	n/a	Redundant coverage
Interaction bugs	❌	✅	n/a	AMST-only
Temporal/expiration gaps	❌	✅	n/a	AMST-only
Missing code	❌	✅	n/a	AMST-only
Provider-specific blind spots	✅	❌	n/a	Three-Cycle-only
Severity misclassification	❌	❌	✅	URV-only
Adjacent bugs	❌	❌	✅	URV-only

Theoretical Foundation

This methodology builds on:

• Vijayaraghavan et al. (2026), Multi-agent organizational intelligence and the "Team of Rivals" architecture
• Reason (1990), Swiss cheese model of layered defenses
• Isotopes AI (2026), The Orchestration Imperative for AI Agents

The convergence of multiple independent research efforts on the same principles provides validation that multi-model orchestration is a generalizable pattern. AMST extended this by applying adversarial thinking not just across models (inter-model) but within a single model's analysis of the full architecture (intra-model, structured enumeration).

V4.0 extends this further by recognizing that finding bugs is only half the work: triaging them for actual severity and surfacing adjacent ones requires its own structured technique. URV provides that triage step.

Citation

If you use this methodology in your work, please cite:

@misc{barrera_castanon_mmasa_2026_v4,
  author       = {Barrera Castañón, Luis},
  title        = {{MMASA}: Multi-Model Adversarial Security Assessment},
  year         = {2026},
  month        = {6},
  url          = {https://github.com/LBCplus/Multi-Model-Adversarial-Security-Assessment},
  note         = {Version 4.0, includes URV methodology}
}

License

This methodology framework, blind spot taxonomy, and documentation are licensed under CC BY 4.0. You are free to share and adapt this material for any purpose with appropriate attribution.

Author

Luis Barrera Castañón, Ed.D. Founder & CEO, Lived Experience Inc. ORCID: 0009-0005-1652-0099

---

This methodology was developed with assistance from Claude (Anthropic) and ChatGPT (OpenAI). See the full methodology document, the AMST document, and the URV document for AI assistance disclosures.