Why do LLM applications create a larger attack surface than traditional software?

Why This Matters for Security Teams

LLM applications enlarge the attack surface because the model can turn untrusted text into decisions, tool calls, data retrieval, or policy-relevant output. That blurs the line between input handling and execution, so attackers do not always need a code defect to influence behaviour. Guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point to the same operational reality: provenance, prompt handling, and tool authorization are security controls, not just application features.

NHIMG research shows how quickly this becomes practical risk. In AI Agents: The New Attack Surface, SailPoint reports that 80% of organisations say their AI agents have already acted beyond intended scope. That is the key difference from traditional software: a static web app usually processes inputs within predictable code paths, while an LLM stack can reinterpret content, chain tools, and expose data through the model layer itself. In practice, many security teams encounter this only after an assistant has already retrieved, summarised, or transmitted something it should never have touched.

How It Works in Practice

Traditional software tends to separate user input, application logic, and privileged actions more cleanly. LLM systems weaken that separation. A prompt, uploaded file, email, ticket, or retrieved document can become operational context, and the model may use it to decide what to answer, what to fetch, or which tool to call. That is why security teams now treat prompt injection, indirect prompt injection, data exfiltration through outputs, and tool abuse as first-class risks.

Practitioners should think in terms of runtime trust decisions rather than one-time input sanitisation. Current best practice is evolving toward:

• content provenance checks so the system knows whether text came from a trusted system, a user, or the public web
• tool-level authorization so the model cannot call high-impact functions by default
• least-privilege context windows so the model only sees what it needs for the task
• output controls that prevent sensitive data, secrets, or policy decisions from being emitted unchecked
• logging that records which content influenced which action, for later investigation

NHIMG’s Top 10 NHI Issues and the OWASP NHI Top 10 both highlight that identities and secrets inside LLM workflows are often over-scoped, under-monitored, and reused across too many pathways. The result is a larger attack surface not because the model is “more complex” in the abstract, but because it creates extra decision points where attacker-controlled content can shape execution. These controls tend to break down when the LLM is connected to broad tool access, long-lived secrets, and unsanitised external retrieval, because the model can chain small permissions into high-impact actions.

Common Variations and Edge Cases

Tighter model controls often increase latency and operational overhead, requiring organisations to balance safety against usability and delivery speed. There is no universal standard for this yet, so teams should be explicit about which risks they are optimising for.

Some LLM deployments are only slightly larger in attack surface than a normal web app, while others are dramatically wider. The difference usually comes down to tool scope, data access, and whether the system can act autonomously. A chatbot with no external tools is mainly exposed to manipulation of answers. An agent with email, source control, payment, or cloud permissions becomes a workflow execution layer, which is far more dangerous.

Edge cases also matter. RAG systems can import malicious instructions from retrieved documents. Multimodal systems can hide instructions in images or PDFs. Multi-agent pipelines can pass compromised context from one component to the next. And if secrets are available in the same runtime as the model, the blast radius can extend beyond the application boundary. For implementation guidance, CSA MAESTRO agentic AI threat modeling framework and the Anthropic first AI-orchestrated cyber espionage campaign report both underscore how quickly model-mediated workflows can be turned into attack paths when trust boundaries are thin and oversight is weak. The guidance breaks down most often in environments that let models act across multiple systems with persistent credentials and minimal human review.

Related resources from NHI Mgmt Group

• Why do NHIs create a larger attack surface than human users?
• Why do AI agents create a larger attack surface than ordinary automation?
• Why do AI agents create more identity risk than traditional LLM applications?
• Why do agent harnesses create a larger attack surface than the model itself?