Why do different LLMs create different security risks for the same application?

Why This Matters for Security Teams

Different LLMs can change the threat profile of the same application because the model is part of the control surface, not a neutral component. One model may be more resilient to prompt injection, while another may be better at following tool instructions and therefore more capable of causing harmful side effects if compromised. That means security review has to cover model behavior, not just hosting, data storage, or API authentication. The NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both reflect this shift toward model-aware risk thinking.

Practically, this affects sensitive data handling, retrieval quality, tool authorization, and the trust placed in model outputs. A safer model in one workflow may become riskier in another if context windows are larger, guardrails are weaker, or output fidelity encourages overreliance. The result is that model selection can alter exposure to data leakage, prompt manipulation, indirect exfiltration, and unsafe autonomous actions. In practice, many security teams encounter these issues only after a model swap has already changed tool behavior in production, rather than through intentional model risk testing.

How It Works in Practice

The same application can behave differently across LLMs because each model makes different tradeoffs in instruction following, context retention, refusal behavior, and tool use. Those differences matter most when the application relies on retrieval-augmented generation, sensitive prompts, or agentic actions that can trigger external systems. A model that is accurate on static questions may still be poor at resisting prompt injection, while a model that is more cautious may break legitimate workflows by over-refusing or truncating context.

Security teams should evaluate models against the actual workflow, not generic benchmark scores. That means testing how each model handles malicious instructions in user input, hidden instructions in retrieved content, jailbreak attempts, and malformed tool responses. It also means checking whether the model preserves boundaries between system instructions, user content, and retrieved documents. Where the application includes agents, the question becomes whether the model can be trusted to select tools, pass arguments, and stop when it should. Guidance in the NIST AI 600-1 Generative AI Profile is especially useful here because it links generative AI behavior to governance, measurement, and monitoring.

• Test each model with the same prompt set, retrieval corpus, and tool permissions.
• Measure refusal behavior, hallucination rates, and resistance to instruction override.
• Review data exposure paths, including logs, traces, embeddings, and cached outputs.
• Validate whether the model changes risk when context length or tool access increases.
• Treat model updates as security-relevant changes that require retesting.

For adversarial scenarios, the MITRE ATLAS adversarial AI threat matrix helps structure testing around poisoning, evasion, and post-deployment abuse. These controls tend to break down when teams rely on vendor labels like “safer” or “enterprise-grade” without testing the model inside the exact application, data, and privilege boundaries it will actually operate in.

Common Variations and Edge Cases

Tighter model controls often increase integration overhead, requiring organisations to balance safety against latency, cost, and product usability. That tradeoff becomes sharper when different teams want different models for the same application, because a model that is acceptable for summarisation may be unacceptable for autonomous ticket creation or code execution.

There is no universal standard for model equivalence yet. Two LLMs may appear similar in demos but diverge materially once they face long context windows, multilingual prompts, or untrusted retrieval content. Some models are more predictable but less capable, while others are more capable but more difficult to constrain. Best practice is evolving, but current guidance suggests defining model-specific acceptance criteria for prompt injection resistance, output validation, and tool-call safety before go-live. The CSA MAESTRO agentic AI threat modeling framework is useful when the application includes delegated actions or chained workflows.

Edge cases also appear when the model is swapped for cost reasons, routed dynamically across providers, or fine-tuned on sensitive organisational data. In those environments, behaviour can drift even when the user interface stays the same. Teams should also account for whether a model’s improved capability creates a new security risk, such as enabling more convincing social engineering content or faster malicious automation. A model change is not only a quality change. It can also alter the blast radius of a compromise.

Related resources from NHI Mgmt Group

• Why do IoT and ot environments create different security risks from standard IT systems?
• Why do local AI models create different security risks than cloud-hosted AI services?
• Why do PCI DSS, HIPAA, GDPR, and CCPA create different compliance demands for the same data security programme?
• Why do AI-generated codebases create different risk conditions for application security programmes?