LLM security: securing the layered stack behind an LLM application

LLM security is the practice of protecting a large language model application across every layer that serves it: the model, the prompts and retrieved context it consumes, the inference server that runs it, the orchestration software that routes to it, and the code that handles what it returns. Here, LLM means large language model, not the postgraduate law degree.

Most published guidance on this topic stops at the model. This page starts where the model stops. The layers underneath, meaning the inference server, the distributed compute framework, the retrieval store, and the gateway in front of them, are ordinary software with ordinary CVE identifiers, fixed versions, and in several cases federal remediation deadlines. That is the part a security team can act on this week.

What LLM security covers, and where this page focuses

A large language model is a model trained on very large text corpora to predict and generate text. In an enterprise deployment it almost never runs alone. It sits behind an API, draws on retrieved documents, calls tools, and returns output that other software consumes. Each of those connections is a place where something can go wrong, and only some of them involve the model at all.

That is the distinction most guidance blurs. Model safety and model security overlap without being the same thing. Red Hat's engineering analysis of LLM system risks, published 2024-11-18, draws the line cleanly: "If a LLM system uses the output of a LLM, and that negatively impacts confidentiality, integrity or availability, then it creates a security vulnerability." A model that returns a biased or wrong answer has a safety problem. A model whose answer is passed unescaped into a shell command, a database query, or a privileged API call has a security problem, and that problem lives in the component that trusted the output.

This page covers the stack that serves the model, and it is deliberately narrow. The full risk taxonomy belongs to GenAI security. Prompt-injection depth belongs to prompt injection. Umbrella coverage belongs to AI security, and adversarial testing belongs to AI red teaming. What you get here is a layer-by-layer inventory, the vulnerabilities tracked against those layers, what the application emits that a security team can use, and how to read the numbers a vendor quotes at you.

The LLM application stack, layer by layer

An LLM application is roughly eight layers deep, and the ranking literature on this topic covers about three of them. The layers a developer touches are documented heavily. The layers an operations team owns are close to silent.

• Model. The trained weights and architecture that generate text.
• Prompt and context. The system prompt, the user input, and everything else assembled into the context window.
• Retrieval and vector store. The document corpus and the embedding database queried before the model answers. In a retrieval-augmented assistant, the corpus is the security boundary, not the chat interface.
• Tool and function calling. The functions the model is permitted to invoke, and the privileges attached to them.
• Inference server. The service that loads the model into memory and answers requests against it.
• Orchestration and distributed compute. The software that routes requests, schedules work across machines, and connects models to tools and data.
• Model artifact and serialization. The file format the weights ship in, and the code that deserializes it.
• Output handling. The code that consumes whatever the model returns.

Developers own the first four. Platform and operations teams own the next three, and output handling usually belongs to whichever application team wired it up. That split matters, because the CVE-bearing layers sit almost entirely on the operations side and are frequently deployed without a named security owner.

Prompt injection, the manipulation of model behavior through crafted input, is the best-known risk at the prompt and context layer, and it is covered in depth on its own page rather than here. Unmanaged or unsanctioned inference endpoints inside your estate are a shadow AI problem before they are an LLM problem. Where the model is permitted to act rather than answer, the tool-calling layer becomes an agentic AI security problem.

‍

The serving and orchestration layer has ordinary, patchable CVEs

Everything above is architecture. This is the part you can act on.

The serving and orchestration layer is the one place where LLM security reduces to three familiar verbs: inventory, patch, and restrict. These components have CVE identifiers, fixed versions, and public vulnerability records, and several carry federal remediation deadlines. None of that requires a machine-learning background to action.

Layer and componentCVE IDScorers and scoresFixed version and statusInference server, vLLMCVE-2026-22778Two Secondary scorers at 9.8 CRITICAL. No NVD Primary scoreAffects 0.8.3 to below 0.14.1, fixed in 0.14.1. Not in KEVInference server, OllamaCVE-2026-7482The same CNA publishes 8.8 HIGH under CVSS 4.0 and 9.1 CRITICAL under CVSS 3.1. No NVD Primary scoreFixed in 0.17.1. Not in KEVInference server, NVIDIA TritonCVE-2026-47627NVIDIA as CNA, 9.8 CRITICAL under CVSS 3.1. NVD not yet assessedAffects 0.0 to 26.05. Not in KEVDistributed compute, RayCVE-2023-48022NIST as NVD Primary, 9.8 CRITICAL. CISA-ADP as Secondary, 9.8 CRITICALFormally tagged disputed. Token authentication available at 2.52.0 and later. Not in KEV, SSVC exploitation proof of conceptDistributed compute, RayCVE-2025-62593NIST as NVD Primary, 8.8 HIGH under CVSS 3.1. GitHub as CNA, 9.4 CRITICAL under CVSS 4.0Fixed in 2.52.0. Added to KEV 2026-08-17, due 2026-08-20ML lifecycle, MLflowCVE-2026-64849GitHub as CNA, 9.3 CRITICAL under CVSS 3.1. NVD has published no Primary score despite marking the record AnalyzedFixed in 3.15.0. Added to KEV 2026-08-19, due 2026-09-02LLM gateway, LiteLLMCVE-2026-42271NIST as NVD Primary, 8.8 HIGH, vector PR:L, meaning an authenticated callerAffects 1.74.2 to 1.83.6, fixed in 1.83.7. Added to KEV 2026-06-08, due 2026-06-22Retrieval-augmented assistantCVE-2025-32711Microsoft as CNA, 9.3 CRITICAL. NIST as NVD Primary, 7.5 HIGHNot in KEV, SSVC exploitation none

Caption: Vulnerabilities tracked against the LLM serving and orchestration layer, as of 2026-08-25. This is a date-stamped sample, not an exhaustive list. Alt text: Table of eight LLM infrastructure vulnerabilities showing the affected layer and component, CVE identifier, each scoring organization with its score, and the fixed version and KEV status.

Two disciplines make that table usable. First, name the scorer. A CVE Numbering Authority (CNA) score is not an NVD score, and on this stack they disagree often. CVE-2026-7482 carries 8.8 under CVSS 4.0 and 9.1 under CVSS 3.1 from the same CNA, and NVD has published no independent base score despite marking the record Analyzed, so "9.1 according to NVD" is wrong. Second, read the description rather than the headline. CVE-2026-22778 is not a single-bug remote code execution: NVD classifies it under CWE-209 and CWE-532, both information-disclosure weaknesses, and describes a heap-address leak that "can be chained a heap overflow with JPEG2000 decoder in OpenCV/FFmpeg to achieve remote code execution."

The volume on this layer is neither marginal nor static. An NVD keyword census run on 2026-08-25, reading the totalResults field for each product name, returns 129 records for Flowise, 70 for vLLM, 68 for LangChain, 63 for Triton Inference Server, 36 for Ollama, 35 for llama.cpp, 30 for LiteLLM, 18 for SGLang, and 4 for TorchServe. Five days earlier three of those counts were lower, at 69, 67, and 32, and none was higher. Concentration shows too: five NVIDIA Triton Inference Server CVEs were published on 2026-08-18, topped by CVE-2026-47627 at 9.8 CRITICAL, and all five are Secondary-scored with no NVD Primary.

The clearest governance story on this layer is Ray. Two authorities score CVE-2023-48022 at 9.8 CRITICAL, and NVD formally tags the record disputed, because the vendor's position is that "Ray, as stated in its documentation, is not intended for use outside of a strictly controlled network environment." Disputed records fall out of some vulnerability-management workflows. That CVE is absent from CISA's Known Exploited Vulnerabilities (KEV) catalogue and CISA's Stakeholder-Specific Vulnerability Categorization records its exploitation state as proof of concept, while MITRE tracks a campaign exploiting it as C0045 ShadowRay. Meanwhile a different, undisputed Ray vulnerability, CVE-2025-62593, entered KEV on 2026-08-17 with a due date of 2026-08-20, and its fix is version 2.52.0: the exact version the disputed record names as the one where token authentication became available. Secure by deployment assumption is not a control.

KEV is the sharpest operational filter here. As of 2026-08-25 the catalogue holds 1,675 records, of which ten are LLM-stack components: six Langflow records, two LiteLLM, one Ray, and one MLflow. None of the four CVEs this topic usually names is among them. Rebuild your inventory around the orchestration layer rather than around the two or three brands the coverage repeats.

Exposure at this layer is real but poorly measured, and not one of the scans below states its method. SecurityWeek, reporting Cyera in May 2026, put the figure at "approximately 300,000 Ollama servers currently exposed on the public internet". A June 2026 analysis of stolen AI compute reported "roughly 175,000 publicly exposed Ollama instances across more than 130 countries". In a scan window its authors state as November 2024, Trend Micro found "over 3,000 servers completely open" and, for llama.cpp, "80 exposed servers, and 57 of them did not appear to have any form of authentication". SecurityWeek on the Ray campaign in November 2025 carried another firm's count of "more than 230,000 Ray servers accessible from the web". NVD's own record for CVE-2026-7482 gives no number and says only that there is "large public-internet exposure observed". Treat the range, the dates, and the missing methods as the finding.

Validating the patch is a separate job from applying it, which is where AI red teaming earns its place. Treat the table as perishable: CVE content ages fast, the KEV catalogue changes weekly, and this is a sample rather than an inventory. Give it a named owner and a defined review interval.

Model artifacts, and the measured limits of scanning

A model artifact is executable code in a data wrapper. That is the whole problem in one sentence.

The mechanism is a sequencing failure. A scanner such as picklescan "first validates Pickle files and, if they are validated, performs security scanning", while Pickle deserialization "works like an interpreter, interpreting opcodes as they are read". Scanning happens before loading. Execution happens during loading. Anything that makes a file look invalid, unfamiliar, or malformed to the scanner while remaining loadable by the framework passes straight through that gap.

‍

That gap is not theoretical, and it has now been measured three ways.

In February 2025, exactly two malicious models were found on a public model hub using a technique named nullifAI, which evaded the scanner by compressing the artifact with 7z instead of the ZIP format the framework traditionally uses. Two, not many. The value of that case is the mechanism, not the volume.

Between February and March 2025, four separate scanner bypasses were assigned CVE identifiers. Their scorer disagreement is wider than anything in the previous section.

CVE IDCNA score (CVSS 4.0)NVD Primary score (CVSS 3.1)What it bypassedCVE-2025-17165.3 MEDIUM9.8 CRITICALpip was not treated as an unsafe global, so a model that pulled a package through it passed the scanCVE-2025-18895.3 MEDIUM9.8 CRITICALOnly standard pickle file extensions were in scope, so a non-standard extension was never scannedCVE-2025-19445.3 MEDIUM6.5 MEDIUMA modified ZIP header crashed the scanner while the framework still loaded the modelCVE-2025-19455.3 MEDIUM9.8 CRITICALFlipped ZIP flag bits hid the pickle file from the scanner but not from the loader

Caption: Four CVE-tracked bypasses of a widely used model scanner, all published between February and March 2025, with a 4.5-point scorer gap on three of the four. None is in the KEV catalogue as of 2026-08-25. Alt text: Table of four model-scanner bypass vulnerabilities comparing the CNA CVSS 4.0 score of 5.3 against NVD Primary CVSS 3.1 scores of 9.8, 9.8, 6.5, and 9.8, with the evasion technique for each.

In July 2026 a preprint put a number on it. ShadowPickle describes three stealthy pickle deserialization attacks and reports that the family "evades ten SOTA scanners, and four model hubs". Its Overwritten variant separately "has a 63% evasion rate across scanners, and up to 50% higher evasion rates than existing attacks". The paper attaches no scanner count and no hub count to that 63%. It is a preprint, not peer reviewed, single-source, and without independent replication, so treat the figure as a reason for concern rather than a number you can bank. The direction is the point: the scanning control most teams rely on has a published evasion rate rather than an assumed one.

The supply chain is also wider than the model file. A first-party model hub incident disclosure published 2026-07-16 records that the breach began with a malicious dataset rather than a malicious model: "A malicious dataset abused two code-execution paths in our dataset processing (a remote-code dataset loader and a template-injection in a dataset configuration) to run code on a processing worker." From there, in the hub's own words, "the actor escalated to node-level access, harvested cloud and cluster credentials, and moved laterally into several internal clusters over a weekend."

The controls that apply here are unglamorous. Prefer safetensors over Pickle for any format you control, require provenance for artifacts you do not control, and load untrusted models inside a sandbox built on the assumption that loading is execution.

What an LLM application emits, and what a SOC can act on

A guardrail tells you what it blocked. Almost nothing tells you what it missed.

That asymmetry is the visibility problem at this layer, and one caveat has to come before the table: no authoritative public inventory of LLM application telemetry exists yet, so the table below is reasoned from the components rather than cited from practice. Use it as an architecture prompt, not as a standard.

EventEmitting componentWhy it is security relevantWhat its absence hidesPrompt and completion recordApplication or gatewayThe only record of what was asked and what was answeredData exfiltration through the model, and abuse of a legitimate accountGuardrail verdict and matched ruleGuardrailShows what was blocked and on which ruleEverything the guardrail passedRetrieval query and returned document identifiersRetrieval and vector storeTies an answer to a source corpus and a permission setWhether a user reached documents they should not seeTool or function invocation with argumentsOrchestration layerThe point where generated text becomes actionPrivilege misuse, and the blast radius of a successful injectionModel artifact load event with hash and sourceInference serverEstablishes provenance at the moment of loadingWhich artifact actually ran, and whether it was the approved oneInference server error responsesInference serverError responses are attack surface and leak internal stateReconnaissance against the serving layerAuthentication and authorization decision at the endpointGateway or inference serverDistinguishes an authorized caller from an open endpointUnauthenticated access to a model-upload or job-submission pathToken, cost, and rate anomaliesGatewayDetects resource abuse and compute theft using stolen credentialsUnbounded consumption and quiet cost-based attacks

Caption: A reasoned inventory of what an LLM application can emit, derived from the components in the stack rather than from a cited standard, because no authoritative public inventory exists. Alt text: Table of eight LLM application telemetry events listing the emitting component, the security relevance of each event, and what a security team loses when the event is not collected.

The one authoritative anchor available covers the agentic case. The UK National Cyber Security Centre, writing on 2026-08-20 about managing the cyber risk of agentic AI, states that "Agentic AI activity should be treated as a form of user activity. It should therefore be included in 24/7 security operational monitoring and incident response responses." The phrasing matters: that guidance is about 24/7 security operational monitoring, and it uses neither the word LLM nor the word SOC anywhere. It also specifies what to collect while an agent runs, naming chain-of-thought traces and transcripts from the agent alongside logging events from the wider sandbox environment such as access logs, proxies, and network traffic, and it directs that those logs be protected from modification or deletion.

That last clause is the detection hook. Guardrail and logging tampering maps to T1685 Disable or Modify Tools, which sits under TA0112 Defense Impairment in MITRE ATT&CK and covers adversaries who "disable, degrade, or tamper with security tools or applications" in order to "impair or reduce visibility of defensive capabilities." It is the only ATT&CK technique this page asserts.

Detection is a recognized half of this field even though almost no practitioner page occupies it. A 2025 academic survey of LLM security classifies defenses into "two primary categories: prevention-based and detection-based defenses", which is the same axis every mature security program already runs on.

This section stops deliberately at what the application emits. SIEM integration, detection-rule development, and SOC workflow for generative AI are covered on GenAI security, and applying analytics to this signal is covered on AI threat detection. Where the application acts rather than answers, see agentic AI security.

Guardrails, firewalls, gateways, and scanners, and the numbers they quote

Define these tools by function, because vendor category names and open-source project ownership both shift faster than the functions do.

CategoryWhat it inspectsWhere it sitsWhat it cannot doGuardrailPrompt and response textInside the application, at the model boundaryCannot see the infrastructure below it, and reports only what it blockedLLM firewallPrompt and response textInline in the network request path, in front of the applicationShares the guardrail blind spot, and adds no visibility into in-process callsAI gatewayRequests, routing, quotas, and credentialsBetween the application and one or more model providersDoes not inspect model artifacts and does not test model behaviorModel scannerThe serialized model artifact, before it loadsIn the build pipeline or at the model hubHas a measured evasion rate, and sees nothing at runtimeRed-team harnessModel and application behavior under adversarial inputOffline or in a pre-production environmentProduces findings rather than controls, and its scores are harness-specific

Caption: The five functional categories of LLM security tooling, defined by what each inspects and where it sits rather than by vendor category name. Alt text: Table comparing guardrail, LLM firewall, AI gateway, model scanner, and red-team harness by what each inspects, its position in the request path, and its principal limitation.

An LLM guard, to answer the common question directly, is a guardrail: a control that inspects prompts or responses at the application boundary and blocks, redacts, or rewrites them. It is prevention, not detection, and it operates on text crossing the boundary rather than on the infrastructure underneath.

"LLM firewall" is worth defining and not worth chasing. It is a vendor category name for a network-positioned guardrail, and it describes a genuine placement choice: inline in the request path rather than inside the application process.

Choosing between categories is a coverage question, not a ranking question. Ask which layer a tool actually covers, where it sits in the request path, what it does when it fails, whether it emits telemetry or only verdicts, and whether it is the only control on that layer. A guardrail and a model scanner do not compete, because they cover different layers. AI red teaming harnesses replace neither, they test both. And nothing in that table prevents prompt injection outright.

‍

How to read an LLM security benchmark

An attack success rate (ASR) is the share of attempts a harness scored as successful against a target model. It is meaningful inside its own harness and almost nowhere else.

Three variables move that number independently: the prompt set, the judging protocol, and the definition of success. Change any one and the figure moves, which is why two published attack success rates are rarely comparable even when they describe the same attack class. The StrongREJECT benchmark paper states the direction explicitly, noting that "it is perhaps more common than not for jailbreak developers to substantially exaggerate the effectiveness of their jailbreaks" and that "existing evaluation methods significantly overstate jailbreak effectiveness compared to human judgments". Note the direction, and note that the paper attaches no percentage to the overstatement. Anyone quoting one is quoting something else.

So ask four questions of any vendor figure: which harness, which judge, which prompt set, and what counted as success. If those four answers are not available, the number is a marketing artifact rather than a measurement.

Framework and regulatory mapping, version pinned

Most of the frameworks on this page moved in the last thirteen months, so the version and the date matter more than the name.

2025 ID and title2026 ID and titleMovementNoteLLM01:2025 Prompt InjectionLLM01:2026 Prompt InjectionUnchangedHeld the top position across both editionsLLM02:2025 Sensitive Information DisclosureLLM02:2026 Sensitive Information DisclosureUnchangedHeld second across both editionsLLM03:2025 Supply ChainLLM04:2026 Supply ChainDown 1Covers the model-artifact section aboveLLM04:2025 Data and Model PoisoningLLM05:2026 Data and Model PoisoningDown 1Renumbered, so a 2025 identifier now misleadsLLM05:2025 Improper Output HandlingLLM10:2026 Improper Output HandlingDown 5The largest single move in the listLLM06:2025 Excessive AgencyLLM03:2026 Excessive AgencyUp 3Tracks the shift toward agentic deploymentsLLM07:2025 System Prompt LeakageLLM08:2026 Hidden Context ExposureDown 1, renamed and broadenedScope widened from the system prompt alone to all hidden context, including retrieved policy text and the schemas of tools the application exposes to the modelLLM08:2025 Vector and Embedding WeaknessesLLM09:2026 Vector and Embedding WeaknessesDown 1The retrieval and vector store layerLLM09:2025 MisinformationLLM07:2026 MisinformationUp 2LLM10:2025 Unbounded ConsumptionLLM06:2026 Unbounded ConsumptionUp 4

Caption: Crosswalk between the 2025 and 2026 OWASP Top 10 for LLM applications. The 2026 column is taken from the canonical repository, the 2025 column from the superseded list page, and the rename from Help Net Security's coverage, all read on 2026-08-25. Alt text: Crosswalk table mapping each 2025 OWASP LLM Top 10 identifier to its 2026 identifier, showing two entries unchanged and the other eight moved, with one of those eight also renamed and broadened.

Two entries hold position and the other eight all move. One of those eight was also renamed and broadened: Help Net Security's coverage of the release records that "System Prompt Leakage was renamed and broadened to Hidden Context Exposure." Nothing was dropped and nothing is wholly new, which matters if you are mapping 2025 controls onto the 2026 list. The 2026 edition was published on 2026-08-04 and combines community judgment with incident data: the same coverage records that "the vote still carried 75% of the weight, but the remaining 25% was influenced by the data from 6,639 real incidents pulled from public vulnerability databases and an AI-harm database." The list is not re-enumerated here. Per-risk descriptions belong on GenAI security, and the 2026 list is available in aggregate from its OWASP resource page. Version drift is live rather than hypothetical: twenty-one days after release, the older list page still served only 2025 identifiers, which is why the crosswalk cites each column to its own source.

FrameworkVersionAs ofWhat it maps to on this pageOWASP Top 10 for LLM applications2026 edition, published 2026-08-042026-08-25The risk taxonomy, crosswalked aboveMITRE ATT&CK Enterprisev19.2, 15 tactics2026-08-25The single technique mapping in the telemetry sectionMITRE ATLAS2026.07: 1 matrix, 16 tactics, 101 techniques, 77 sub-techniques, 37 mitigations, 68 case studies2026-08-25AI-specific adversary behavior, and the naming conflict belowNIST AI Risk Management Framework1.0, released 2023-01-26, under revision2026-08-25Program governance across Govern, Map, Measure, and ManageNIST AI 100-2 E2025Final, March 20252026-08-25Adversarial machine learning taxonomy and terminologyEU AI ActRegulation (EU) 2024/1689, consolidated 2026-07-27, amended by Regulation (EU) 2026/17442026-08-25Transparency and high-risk obligations, and their application datesISO/IEC 420012023 base text, EN ISO/IEC 42001:2026 European adoption2026-08-25AI management system certification, dates secondary-sourced only

Caption: Version-pinned framework mapping for this page, verified as of 2026-08-25. MITRE ATLAS ships monthly calendar versioning, so re-check the release before relying on the element counts. Alt text: Table pinning seven frameworks to a specific version and verification date, with a note on what each maps to in this article.

One mapping trap is worth knowing. MITRE ATT&CK Enterprise v19.2 has exactly 15 tactics and none is named Defense Evasion: TA0005 is now Stealth and TA0112 is Defense Impairment. MITRE ATLAS release 2026.07 still carries a tactic named AML.TA0007 Defense Evasion, and that ATLAS record's own attack-reference field points at TA0005. The two frameworks are formally cross-referenced while disagreeing on the name of the same mapped concept, so any statement about Defense Evasion has to say which framework it belongs to.

On regulation, the EU AI Act's Article 50 transparency obligations applied from 2 August 2026 and were not deferred. Regulation (EU) 2026/1744 moved the high-risk obligations: Annex III high-risk systems will apply from 2 December 2027 and Annex I from 2 August 2028. Under the consolidated text, providers of systems generating synthetic content already on the market must comply with Article 50(2) by 2 December 2026, and Articles 102 to 110 applied from 27 July 2026. These are the most volatile dates on this page, so re-verify them against EUR-Lex, alongside whatever AI governance tools you use to track them.

Two further anchors matter for program-level work: the NIST AI Risk Management Framework, released 2023-01-26 and now "being revised as part of the White House AI Action Plan", and NIST AI 100-2 E2025, the final March 2025 taxonomy of adversarial machine learning attacks and mitigations. ISO/IEC 42001 is the management system standard for AI, and EN ISO/IEC 42001:2026 is the current European adoption of the same base text, superseding a withdrawn 2025 national adoption. Its publication dates are secondary-sourced here, because the standards body's pages are not publicly fetchable.

Modern approaches to securing the LLM stack

Budget is moving toward this layer. Enterprise Technology Research's 2026 State of Security report, based on 517 security-focused technology leaders and published with no stated survey field dates, found that "more than half (59%) of organizations plan to increase spending in this category", while "a fifth (20%) of organizations report having no agent-specific security controls in place, and only 3% have deployed them broadly across production environments."

The design thesis the OWASP project leads put forward for the 2026 edition is blast-radius control rather than perfect prevention. As Help Net Security's coverage of the release records them opening: "Stop trying to build a model that cannot be fooled." In practice that resolves into three capabilities: posture management across the AI estate, covered under AI security posture management; runtime detection over the serving layer; and provenance over the model artifact. The wider program is specified in the NCSC's Guidelines for secure AI system development, across secure design, secure development, secure deployment, and secure operation and maintenance. The forward-looking work is narrower: apply the same inventory-and-patch discipline to orchestration components that today have no security owner.

How Vectra AI thinks about LLM security

Vectra AI starts from the position that the modern network is a single attack surface, and the LLM serving stack is now part of it. The assume-compromise posture applies here exactly as it does to identity, cloud, and on-premises infrastructure. Prevention at the prompt boundary is necessary and insufficient. What matters operationally is observability over the AI infrastructure segment, a signal that separates real attacker behavior from model noise, and the ability to act on that signal. That is the methodology behind Attack Signal Intelligence, applied to a segment most estates have not yet inventoried, and it is where AI security programs are heading next.

LLM security is a stack discipline. Inventory the layers you own, patch the components carrying CVE identifiers and KEV deadlines, instrument what your applications emit, and read every vendor number back to the harness that produced it. The model is the part everyone writes about. The stack underneath it is the part you can fix.

‍