[{"content":"A security engineer sits down to threat-model a legal document analysis pipeline that runs on a large language model. They open their STRIDE template and stall at Tampering. The binaries are signed. Transit is TLS. Database writes are authenticated. And yet, the runtime has been hijacked: someone uploaded a benign-looking PDF with crafted instructions hidden in invisible text, and the model dutifully exfiltrated private user sessions. From the perspective of classical threat modelling, every data flow is authorised, every file is intact, no exploit code ran. But the control flow of the application is gone.\nThis is the friction point I want to talk about. The issue isn\u0026rsquo;t that classical threat modelling has become obsolete — it\u0026rsquo;s that we\u0026rsquo;re asking it to evaluate a different kind of system. STRIDE, DREAD, PASTA didn\u0026rsquo;t fail. They met a probabilistic system, and their categories don\u0026rsquo;t quite fit.\nThe foundations of classical threat modelling Before getting to where the gap opens, it\u0026rsquo;s worth being clear about what classical threat modelling does well.\nDecades of application security practice have produced structured methods for catching design flaws early. STRIDE remains the most widely used. It categorises threats as Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, or Elevation of Privilege, surfaced by walking the data flows and trust boundaries of a system. DREAD is the older risk-scoring companion: Damage, Reproducibility, Exploitability, Affected Users, Discoverability. PASTA (Process for Attack Simulation and Threat Analysis) is the more business-aligned, attacker-centric alternative, structured around seven stages.\nThese methods remain genuinely useful. Most corporate AI deployments are not autonomous neural systems. They are conventional web applications with an API call to a hosted language model in the middle. STRIDE handles those well and it still catches SQL injection in adjacent databases, XSS in presentation layers, and authentication failures at the integration gateway.\nThe breakdown happens at a single assumption, that a system is made of discrete, deterministic components with well-defined trust boundaries. When one of those components is a language model, that assumption stops being true.\nThe paradigm shift in system architecture Three architectural shifts make LLM applications behave differently from the systems classical threat modelling was designed for.\nThe input channel as an execution interface In classical systems, parsers, schemas, and validators keep user input separate from execution instructions. With language models, that separation collapses. Instructions and data live in the same natural-language context. Prompt injection isn\u0026rsquo;t a parsing error or a syntax bug. It\u0026rsquo;s the model behaving exactly as designed. Interpreting natural-language instructions, regardless of who wrote them.\nThe pattern comes in two flavours. Direct prompt injection is the user overriding system instructions to force unintended behaviour. Indirect prompt injection is more interesting: the model processes external data (a summarised web page, an email, an uploaded PDF) and the data itself contains the instructions. Multimodal inputs and adversarial suffixes extend this further. The input layer is no longer just user-controlled. It is anyone-controlled.\nThe model as an asset class of its own In a conventional application, your assets are source code, binaries, configuration files, databases. In an AI system, the model itself is an asset class and a larger one than it first appears. Pre-training data, fine-tuning datasets, weights, system prompts, RAG indexes, agent tool definitions. All of these can be exfiltrated, modified, or poisoned. STRIDE has no column for \u0026ldquo;the model leaks its own system prompt through legitimate output.\u0026rdquo;\nEmergent, non-deterministic execution Traditional software is deterministic. Trace the code, follow the control flow, and you can predict the output. Language models don\u0026rsquo;t work that way. Identical inputs can produce different outputs depending on sampling parameters, model state, and context. Behaviour emerges statistically from training data, not procedurally from code. That means threat models can\u0026rsquo;t assume there is a specification to test against.\nThe modern security vocabulary Three specialised frameworks have emerged to fill these gaps. They aren\u0026rsquo;t competing — they\u0026rsquo;re complementary, and each addresses a different layer.\nOWASP Top 10 for LLM Applications The OWASP Top 10 for LLM Applications (2025) is the direct analogue to the classic OWASP Top 10 for web apps. It catalogues the ten most critical risks for deployed LLM systems and is aimed squarely at application security teams. Its categories include Prompt Injection (LLM01), Sensitive Information Disclosure (LLM02), Supply Chain Vulnerabilities (LLM03), Data and Model Poisoning (LLM04), Improper Output Handling (LLM05), Excessive Agency (LLM06), System Prompt Leakage (LLM07), Vector and Embedding Weaknesses (LLM08), Misinformation (LLM09), and Unbounded Consumption (LLM10).\nMITRE ATLAS Where OWASP asks \u0026ldquo;what can go wrong,\u0026rdquo; MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) asks \u0026ldquo;how would an adversary make it happen.\u0026rdquo; Modelled after MITRE ATT\u0026amp;CK, ATLAS catalogues tactics, techniques, and procedures observed in real attacks and red-team work. As of the November 2025 update, the framework covers 16 tactics and 84 techniques.\nMore relevant for what\u0026rsquo;s coming: the February 2026 update extended ATLAS into agentic systems. New techniques around API exploitation patterns, tool credential harvesting, tool-mediated data poisoning, and data destruction via agent tool invocation. The recurring theme is that the agent\u0026rsquo;s tool surface becomes the attack surface.\nNIST AI Risk Management Framework The NIST AI Risk Management Framework sits one level higher. It isn\u0026rsquo;t a threat list. It\u0026rsquo;s a governance scaffold structured around four functions Govern, Map, Measure, Manage and covering the full system lifecycle. The Generative AI Profile (NIST AI 600-1) translates this into around 200 suggested risk-management actions specific to generative systems, including dual-use risks, confabulation, and systemic bias.\nFramework Primary audience Core function Analytical contribution STRIDE / PASTA Security architects, software engineers Trust boundaries, component decomposition, traditional data flows Maps the conventional web infrastructure surrounding the model OWASP Top 10 for LLM Applications AppSec teams, developers Application-layer risks Catalogues which integration-layer risks need mitigating MITRE ATLAS Red teams, threat intelligence Adversary tactics and techniques Details how attackers actually exploit model architectures and agent tools NIST AI RMF CISOs, auditors, governance practitioners Socio-technical risk, lifecycle, policy Frames corporate risk tolerance, compliance, and measurement These frameworks operate alongside classical methods rather than replacing them. STRIDE still maps the data flows of the surrounding ecosystem. OWASP, ATLAS, and the NIST AI RMF extend the practitioner\u0026rsquo;s vocabulary at the precise interface points where classical assumptions break down.\nOperational implications for security teams Adopting this expanded vocabulary changes three things in day-to-day security work.\nA new participant in threat-modelling sessions Threat-modelling sessions need a new participant. Someone who understands how the model actually behaves: token generation, fine-tuning effects, context window limits, model state. In a larger organisation, that\u0026rsquo;s a dedicated AI security engineer. In a smaller one, it\u0026rsquo;s an AppSec engineer who has to grow into the role. Either way, the conversation doesn\u0026rsquo;t work without that voice in the room.\nAn expanded asset inventory Asset management has to evolve beyond cataloguing virtual machines, containers, and databases. Model-side assets like system prompts, retrieval indexes, fine-tuning datasets, agent tool definitions or orchestration configurations need to be inventoried, classified, and protected the same way every other asset is. If they aren\u0026rsquo;t catalogued, they can\u0026rsquo;t be classified. If they can\u0026rsquo;t be classified, they can\u0026rsquo;t be protected proportionally. This is the foundation everything else rests on.\nThe triage question Historically, any project with an AI component was routed to the AppSec queue. That now needs a triage step: is this a web app with an LLM call inside it, or an LLM-native application with direct tool access? The two need different reviews. The first largely fits existing AppSec pipelines, the second needs a process focused on privilege boundaries, tool permissions, and runtime monitoring.\nA note before the rest of the series None of these adjustments are particularly novel. Most security organisations already have variants of them. What\u0026rsquo;s new is the deliberate work of mapping them onto a different kind of system — one without a deterministic specification, with input channels that double as execution channels, and assets that don\u0026rsquo;t show up in any existing inventory. The vocabulary exists. The frameworks are public. What\u0026rsquo;s missing is the habit of looking at AI systems through them.\nThat\u0026rsquo;s what the rest of this series is about.\nThe Foundation series roadmap The next posts translate these shifts into something more concrete:\nPost 2 — Mapping STRIDE to AI-specific threats. A translation matrix that bridges legacy vulnerability categories with the new adversarial frameworks. Post 3 — Model security as a protection object. A look at modern asset inventories: what changes when models, weights, and embeddings become protection objects in their own right. Post 4 — Pragmatic risk profiling. A one-page method that scales from internal search tools to fully autonomous agents. Post 5 — Ten questions for a fast AI security assessment. A short triage checklist designed to classify any AI use case. Post 6 — Enterprise realities of AI risk. Which AI risks actually matter at enterprise scale, and which are mostly literature. Sources:\nOWASP Top 10 for LLM Applications (2025) MITRE ATLAS NIST AI Risk Management Framework + GenAI Profile ","permalink":"https://verbose.run/posts/why-classical-threat-models-no-longer-suffice/","summary":"Classical threat modelling didn\u0026rsquo;t fail. It met a system it wasn\u0026rsquo;t designed for.","title":"Why classical threat models no longer suffice for AI systems"},{"content":"Hi, I\u0026rsquo;m Severin.\nI\u0026rsquo;m a Technical Information Security Officer based in Bern, Switzerland. My day-to-day work revolves around cloud security, collaboration platform security, and the question of how we secure AI systems and the decisions they shape. This blog collects notes on what I\u0026rsquo;m learning, occasional essays, and things I find worth writing down.\nOutside of work, I spend my time running, cycling, and strength training — preferably outdoors and preferably somewhere with mountains nearby. I cook a lot, and I\u0026rsquo;m always planning the next trip, whether that\u0026rsquo;s a long-haul adventure through Scandinavia or a weekend gravel ride. I read widely across security, tech, thrillers, and nonfiction, and I have a weakness for good podcasts on true crime and science.\nOpinions here are my own and don\u0026rsquo;t represent any employer.\nContact Email: hello@verbose.run Security issues: security@verbose.run GitHub: @SeverinJ ","permalink":"https://verbose.run/about/","summary":"\u003cp\u003eHi, I\u0026rsquo;m Severin.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;m a Technical Information Security Officer based in Bern, Switzerland. My day-to-day work revolves around cloud security, collaboration platform security, and the question of how we secure AI systems and the decisions they shape. This blog collects notes on what I\u0026rsquo;m learning, occasional essays, and things I find worth writing down.\u003c/p\u003e\n\u003cp\u003eOutside of work, I spend my time running, cycling, and strength training — preferably outdoors and preferably somewhere with mountains nearby. I cook a lot, and I\u0026rsquo;m always planning the next trip, whether that\u0026rsquo;s a long-haul adventure through Scandinavia or a weekend gravel ride. I read widely across security, tech, thrillers, and nonfiction, and I have a weakness for good podcasts on true crime and science.\u003c/p\u003e","title":"About"},{"content":"Earlier this year, I was asked to give a talk at a community event on a security topic I\u0026rsquo;d been thinking about for a while. Public speaking isn\u0026rsquo;t something I actively seek out. I have never been especially drawn to the spotlight. But the part before the talk, the quiet work of pulling a topic apart and trying to put it back together clearly, interested me a lot. The talk came and went. The preparation, and the kind of thinking it forced, stayed with me.\nThat was what stayed with me. Writing, or any act that forces you to sequence your thoughts on a page, produces a kind of clarity that conversation doesn\u0026rsquo;t. Talking is fast and forgiving. Half-formed ideas get smoothed over by tone and gesture. Writing, even just a page of notes, is merciless. The gaps in your reasoning show up. Sentences you thought were confident turn out to be vague. Over the years, working in security, I\u0026rsquo;ve noticed that the arguments I actually trust are the ones I\u0026rsquo;ve written down at least once.\nSo that\u0026rsquo;s what this is. A place to write things down. Security mostly: not just tools and controls, but the organisational questions around them. That\u0026rsquo;s where most of my working hours go, and where I have something to say. Beyond that, the occasional essay and whatever I\u0026rsquo;m reading when it seems worth mentioning. The primary audience, honestly, is me. If someone else finds it useful, that\u0026rsquo;s a nice side effect. But it\u0026rsquo;s not a newsletter, it\u0026rsquo;s a habit I\u0026rsquo;d like to keep even if nobody reads it.\nThere will be no schedule. No weekly rhythm, no \u0026ldquo;here\u0026rsquo;s what I\u0026rsquo;m working on this month\u0026rdquo;. I\u0026rsquo;ll write when I have something worth writing down, and sometimes that will be often, sometimes it won\u0026rsquo;t. I care less about a clean publishing rhythm than about not turning every unfinished thought into a permanent draft. I\u0026rsquo;d rather publish a rough post that says something than sit on a perfect one that never goes live. If a post sits in drafts for three months, that\u0026rsquo;s probably a sign it should be shorter, not more considered.\nThat is what I want this place to be for: not performance, not output, but a way of noticing what I actually think. That\u0026rsquo;s the experience I\u0026rsquo;d like to extend. The name, by the way, comes from the --verbose flag: the one you pass to a program when the default output doesn\u0026rsquo;t tell you enough. That felt about right for a place meant for thinking out loud.\n","permalink":"https://verbose.run/posts/writing-things-down/","summary":"Why I\u0026rsquo;m writing, and what this place is for.","title":"Writing things down"}]