Security Scenario Explorer — a proposed security-testing direction built on Combinatorics Framework JVM.
Most security tools look for known weaknesses. But some vulnerabilities appear when individually valid requests interact in an unexpected order.
A permission changes while a session remains active. A retry arrives after a timeout. A webhook is delivered twice. An AI agent reads untrusted content while holding access to a privileged tool. Each operation may look legitimate in isolation; the sequence may still violate a security boundary.
Security Scenario Explorer is a proposed workbench for investigating these interaction-driven failures systematically. It builds on Combinatorics Framework JVM, a scenario-modeling and execution framework developed by Yurii B.
It is not positioned as a replacement for vulnerability scanners, DAST, or fuzzers. Its intended focus is security behavior that depends on combinations of context, state, action order, and exceptional events, therefore - reassures you even more in considered direction of potential risks.
Broken access control remains the top category in the OWASP Top 10:2025, which also includes security misconfiguration, authentication failures, insecure design, and mishandling of exceptional conditions. The OWASP API Security Top 10 highlights broken object-level authorization. For AI applications, the OWASP Top 10 for LLM Applications:2025 includes prompt injection and excessive agency.
These risks often require more than a single request to investigate. The relevant question is not only “Does this endpoint reject a bad input?” but also “Does the system preserve its security rules after this sequence of valid actions and unexpected events?”
Instead of starting only from a list of known vulnerability patterns, describe what can vary, what must remain true, and how much execution is acceptable:
The framework plans the experiment before execution, reports candidate counts, and supports budgeted t-way selection using a greedy strategy; it does not claim to find a mathematically minimal test set. Candidates run through configured adapters. Verdicts distinguish application failures from harness or infrastructure problems, and failure triage can reduce a failing case to a small reproducer for verification and regression testing.
Authorization and tenant isolation. Can a user access another tenant’s resource after a role change, or does a stale session retain a capability that should have been revoked?
Authentication and session lifecycle. What happens when credentials expire or are revoked in the middle of a workflow?
Business-logic abuse. Can retries, replays, duplicate transactions, or unusual action ordering violate a financial or data-access invariant?
Configuration interactions. Can a combination of settings or feature flags make a restricted operation reachable?
AI-agent boundaries. Can untrusted content influence an agent to use a tool beyond its granted permissions or bypass an approval requirement?
An AI assistant can help formulate threat hypotheses, build scenario models, interpret results, and suggest follow-up experiments. The human remains responsible for the authorized scope, the security properties being tested, and approval of consequential actions.
A finding should not be accepted because a tool or model calls it a vulnerability. It should be supported by a clearly stated invariant, an observed violation, and a reproducible test. Before trusting a security oracle, calibrate it with a known test defect and confirm that the test can detect the failure it is supposed to detect.
The underlying Combinatorics Framework JVM already supports context, sequence, and event modeling; constraints; plan and candidate counts; budgeted candidate selection; execution through configured adapters; verdict classification; failure-witness triage; checkpoints; and an AI-operator workflow with approval gates.
The security-specific layer is still planned, not demonstrated. That includes reusable security oracles, a scope guard, operating-system-level isolation, a concurrent-dispatch adapter, and ready-made scenario packs beginning with API authorization. Defined event injection covers chosen points in a sequence; it does not by itself test two requests arriving at precisely the same time.
There is also an important safety limitation today: generated Java runs inside the JVM without an operating-system sandbox. A security edition needs explicit scope declarations and target allow-lists, execution limits, timeouts, secret redaction, auditable run records, and isolation for generated code before it can be presented as safe for broader security-testing use.
The first milestone should be a reproducible authorization or business-logic flaw that a single-request test misses. Publish the scenario, the invariant it violates, the observed result, and a minimal reproducer - then rerun it as a regression test.
The goal is not to claim that every attack can be enumerated. It is to make a defined security investigation more systematic, bounded, repeatable, and re-viewable.
Model what must remain secure. Explore the interactions that could break it. Preserve the evidence.
Security Scenario Explorer is a proposed direction, built on Combinatorics Framework JVM. If you work in AppSec, penetration testing, or security-minded QA, share a real cross-feature failure pattern that would benefit from a reproducible scenario model.
Combinatorics Framework - re-assuring safety behavior more, saving QA jobs as a test-space scenario designer-architect/supervising AI