MASTER'S THESIS
Embedding an AI-Driven Cybersecurity Minefield Inside Business Applications
A modular application-level defense prototype designed to inspect semantically suspicious business data after traditional network-layer controls have already allowed the request through.
What if the request looks completely legitimate?
Traditional security controls are effective at detecting many technical attacks, but some threats do not look abnormal at the network layer. A request can use the correct protocol, contain valid fields and arrive through an expected interface while still carrying misleading or fraudulent business information.
My master's thesis explored an additional defensive layer placed directly inside the application workflow. The goal was to inspect the meaning and relationships inside structured business data before the protected application decides to trust it.
Application security after perimeter security.
The prototype assumes that normal network-layer security has already accepted the connection. Instead of looking for malformed packets, malware or known attack signatures, the system looks for suspiciousness in the submitted business data itself.
A simplified tax-submission workflow was used as the experimental environment. The tax domain provided structured data where relationships between identifiers, income, expenses, employment periods and contextual information could be evaluated.
Semantically valid input
A request can contain correctly formatted and individually plausible values while still being suspicious when those values are evaluated together.
Business-logic trust
The threat model focuses on exploiting assumptions in a business workflow rather than compromising the underlying network or application runtime.
Application-level inspection
Security analysis is inserted before the protected business application so a request can be evaluated before normal processing occurs.
Explainable decisions
Multiple analysis components contribute findings and scores so routing decisions can be inspected rather than produced by one opaque detector.
A modular defense layer in the request path.
The prototype was implemented as multiple Python and FastAPI services. A gateway coordinates the analysis, combines the evidence, requests a policy decision and forwards the submission to the appropriate destination.
Four independent evidence layers.
Instead of relying on a single detection mechanism, the prototype analyses every submission from several perspectives and combines those signals into an overall risk assessment.
Rule Engine
Deterministic validation including missing identifiers, negative values, inconsistent employment dates and suspicious expense-to-income ratios.
35% risk weightAnomaly Scorer
Baseline and statistical plausibility checks for outliers, unusual ratios, missing fields, unexpected fields and rare values.
25% risk weightContext Validator
Evaluates relationships such as known employer identities, person-employer associations and expected document structure.
25% risk weightSemantic Assist
A conservative LLM-supported component used to interpret semantic inconsistencies alongside existing contextual evidence. It is deliberately not the final decision-maker.
15% risk weightMore than simply blocking a request.
One of the most important parts of the prototype was what happened after an extreme-risk submission was routed away from the protected application.
The minefield path created a persistent investigation object rather than returning only a route label. This allowed the prototype to preserve the evidence that caused the escalation and support later analyst activity.
Evidence preservation
Original submission, normalized payload, risk assessment, decision result, analysis details and minefield-control metadata were persisted.
Analyst workflow
Cases could move through investigation states, receive analyst notes and trace results, and be resolved with a recorded reason.
Repeated behavior
Later high-risk cases could identify earlier cases involving the same subject or employer and preserve related-case information.
Controlled friction
Progressive-delay metadata could increase for repeated suspicious behavior while automatic blacklisting remained disabled.
Controlled prototype validation.
The system was evaluated through automated tests, manual end-to-end scenarios, generated request batches and latency replay. The goal was to verify the behaviour of the architecture rather than claim production-grade fraud detection accuracy.
These figures represent controlled internal prototype testing using synthetic and generated samples. They should not be interpreted as real-world tax-fraud detection accuracy.
Explainability came with a latency cost.
The prototype used synchronous HTTP communication between several services. Every request waited for analysis, risk fusion, decision logic and downstream routing before returning a result.
This was acceptable for an inspectable research prototype, but it is not suitable as a production performance target. A production design would likely keep fast checks inline while moving deeper semantic or contextual analysis into asynchronous processing.
What the prototype does not prove.
The evaluation used generated and synthetic submissions rather than real taxpayer data.
The primary batch evaluation used 20 requests per configuration, which is useful for prototype validation but not statistical validation.
File-backed storage and local synchronous services were chosen for transparency and development speed rather than production scalability.
The thesis demonstrated a bounded way to include semantic assistance, but did not isolate the LLM's independent detection contribution through full ablation testing.
The main contribution was the architecture.
The project demonstrated that an explainable defense layer can be inserted between incoming structured submissions and a protected business application.
Selected legitimate requests continued into the normal business workflow, while selected suspicious requests were diverted before the protected application trusted them. Severe cases could also become persistent investigation objects containing evidence, analyst activity and repeated-behavior information.
The result is not a production fraud detector. It is a working proof-of-concept for application-level security that treats business meaning as another place where defensive decisions can be made.