COMMENTARY: In December 2025, the UK’s National Cyber Security Centre (NCSC) issued a warning that should give every security team pause: the industry may never solve the challenge of prompt injection in large language models (LLMs).Unlike SQL injection, where parameterized queries enforce a clean separation between data and instructions, LLMs process everything as tokens. There’s no native architectural distinction between what the model gets told to do and what the data's told to process.[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]This isn’t a new concern. OWASP has ranked prompt injection as the No. 1 vulnerability in its Top 10 for LLM Applications since the list was first published in 2023, and it maintained that ranking in the 2025 edition. But most defensive guidance (input filtering, output validation, and guardrails) focuses on the same layer: catching malicious prompts before they reach the model. The NCSC’s believes that this approach, while necessary, may have a ceiling.For organizations deploying AI in regulated environments, that ceiling has real consequences. When a compliance AI tool produces a fabricated citation that enters an SEC filing, the issuer faces strict liability under Section 11 of the Securities Act, and the attorneys and professionals involved face malpractice exposure and potential discipline. “AI hallucinated” is not a defense for any party in the liability chain.Clearly, input filtering alone won’t solve the problem.Raj Sonani, the senior AI product manager and technical lead at LexisNexis who designed this architecture, frames it in terms security teams will recognize: “If input filtering is your firewall, architectural constraint is your network segmentation. You need both – but only one limits the blast radius when the perimeter is breached.”The approach has gained traction. Several well-resourced competitors in the legal AI business have independently converged on architecturally similar constraint patterns over the past 18 months, suggesting that what began as a doctrine-constrained methodology for legal information retrieval has become a domain-constrained reliability standard for regulated AI more broadly.
Defense in-depth, applied to the AI pipeline
Security teams already understand the principle, so they don’t rely on a firewall alone. They layer network segmentation, endpoint detection, access controls, and monitoring. Each layer limits the blast radius if the layer above it fails.The same principle has been applied to AI architectures in regulated industries. One production-scale implementation demonstrates what this looks like in practice: A doctrine-constrained information retrieval architecture, originally developed through academic research at Cornell Tech and subsequently deployed for SEC compliance analytics at LexisNexis, embeds regulatory requirements directly into each pipeline layer as constraints the system cannot violate, regardless of what instructions it receives.Here’s how it works at different layers:- Retrieval layer: The system operates exclusively against a verified corpus of over 16 million SEC filings. The retrieval scope gets fixed architecturally – there’s no pathway for the model to access sources outside the verified corpus, even if instructed to do so.
- Generation layer: Every output must trace to a specific section and paragraph of a source document. Claims that aren’t grounded in retrieved sources are blocked rather than generated. If a prompt injection attempts to make the system fabricate content, the source attribution requirement stops it: there’s no verified document to cite, so no output gets produced.
- Data isolation layer: Client boundaries are enforced by pipeline design, not by access control policy alone. When the platform serves law firms that are adversaries on active transactions, cross-tenant data contamination is prevented architecturally. This satisfies the confidentiality requirements of ABA Model Rule 1.6 while functioning as a security control against data leakage from any vector, including prompt injection.
