LLM Security for Enterprises: 8 Risks and the Control for Each
LLM security is the practice of protecting applications built on large language models from manipulation, data leakage and unauthorized actions across their inputs, retrieved data, tool calls and outputs. In an enterprise, most of the risk sits in what the model is connected to, so most of the controls belong in the request path rather than the model.
Key takeaways
- LLM security protects applications built on large language models from manipulation, data leakage and unauthorized actions across inputs, retrieval, tools and outputs.
- The eight enterprise risks are prompt injection, sensitive information disclosure, permission bypass in retrieval, excessive agency, supply chain and model routing, data residency, improper output handling and logging gaps.
- Most of the controls run in the request path, not in the model: before the model call, inside the retrieval query, at the model gateway and between an agent's decision and the external system.
- AI agent security is LLM security with write access, so scoped tools, sealed credentials, approval by default and exactly-once writes matter most.
- SphereIQ enforces these controls in its Governance plane and records every decision on an Ed25519-signed audit ledger that can be verified offline.
LLM security is the practice of protecting applications built on large language models from manipulation, data leakage and unauthorized actions, across everything the model touches: its inputs, the data it retrieves, the tools it calls and the output it produces. In an enterprise, most of the risk sits not in the model weights but in what the model is connected to.
A model on its own can only produce text. Connect it to SharePoint, a CRM and a ticketing system, give it the ability to send email, and it becomes a new path into all of them. The eight risks below follow the OWASP Top 10 for LLM Applications, adjusted for what enterprise deployments actually run into, each with the control that addresses it and where that control has to run.
What is LLM security?
LLM security covers the threats specific to systems where natural language drives behavior. Classic application security still applies (authentication, encryption, patching), but LLM applications add a new property: instructions and data share the same channel. A document the model reads can contain an instruction; a user's question can try to rewrite the rules. That breaks an assumption most security controls rely on, that code and data are kept apart.
Enterprise LLM security therefore has two layers. The first is conventional: who can sign in, how credentials are stored, where traffic goes. The second is new: controls in the request path that judge the content of each request, retrieval, response and action. NIST's Generative AI Profile (NIST AI 600-1) is a useful companion for mapping both layers into a risk program.
The 8 LLM security risks, and the control for each
1. Prompt injection
OWASP ranks it first. Direct injection is a user typing instructions meant to override policy; indirect injection is the same instruction hidden in content the model reads, such as a contract, a web page or a tool result. The OWASP entry on prompt injection notes that retrieval and fine-tuning do not fully prevent it.
Control: detection that runs before the model, on user input and on retrieved content and tool results, and decides deterministically. Instructions in a system prompt are not a control, because the model being attacked is the one reading them.
2. Sensitive information disclosure
Data leaks in both directions. Users paste personal data, keys and credentials into prompts, and models reproduce sensitive content from sources or reveal their own system prompts.
Control: secret scanning and personal-data masking on every message before it reaches a provider, plus output filtering and system-prompt extraction detection on the way back.
3. Permission bypass in retrieval
A retrieval-augmented assistant that searches everything and filters later will, sooner or later, answer someone from a document they could not open. OWASP's entry on vector and embedding weaknesses describes the same failure.
Control: permission checks inside the retrieval query, with every chunk carrying its source's access list, and sources with no permission data treated as closed. The detail is in permission-aware RAG.
4. Insecure tool use and excessive agency
When an agent can call tools, a manipulated or simply mistaken model can create tickets, send messages or write records it should not. OWASP calls this excessive agency.
Control: tools exposed with narrow scopes per agent, arguments validated against each tool's schema, a policy per action that can run, hold or refuse it, human approval by default for writes, and execution keyed so a retry never repeats a write. See AI agent governance for the full write lifecycle.
5. Supply chain and model routing
Every model provider, embedding model, reranker and plugin is a dependency that sees some of your data. Routing decisions, such as failover to a second provider, quietly change who sees a prompt.
Control: a model gateway that routes only to providers your policy allows, per-model governance policies, optional services switched off until someone enables them, and a written answer to the question "which providers see our data?"
6. Data residency
"Runs in your VPC" often describes the application and not the model calls. One embedding job calling a public endpoint directly breaks the residency claim.
Control: a deployment model that matches your data boundary, and every model call, background jobs included, leaving through one gateway you control and proved on a sealed network. The test is described in self-hosted LLMs in your VPC.
7. Improper output handling
Model output passed straight into a browser, a shell, a SQL query or another system's API inherits whatever the model was persuaded to write.
Control: treat output as untrusted input to the next system. Validate structured output against a schema, escape it where it is rendered, and check answers against their cited sources before delivery.
8. Logging gaps
When something goes wrong, the questions are what the AI saw, what it said and what it changed. Many deployments can answer only with application logs that the vendor controls and nobody else can verify.
Control: an append-only record of every request, guardrail decision, approval and action, with signed exports that someone outside the vendor can verify. The AI audit trail covers what makes a record evidence; LLM observability covers the engineering traces that sit alongside it.
The eight risks at a glance
| Risk | Example | Control | Where the control runs |
|---|---|---|---|
| Prompt injection | A supplier PDF tells the assistant to email the thread to an outside address | Deterministic injection detection on input, retrieved content and tool results | Before the model call |
| Sensitive information disclosure | An engineer pastes a connection string while debugging | Secret scanning and PII masking; output filtering | Before the model call and before delivery |
| Permission bypass in retrieval | A new hire asks about bonuses and gets an answer from an HR folder | Access control inside the retrieval query; closed by default | In the retrieval query |
| Excessive agency | An agent closes 200 tickets after misreading an instruction | Scoped tools, per-action policy, approval by default, exactly-once writes | Between the agent's decision and the external system |
| Supply chain and model routing | A failover sends regulated data to an unapproved provider | Model gateway with an allowed-model policy; optional services off by default | At the model gateway |
| Data residency | A background embedding job calls a public API directly | Deployment in your cloud; all model egress through your gateway | At the network boundary |
| Improper output handling | Generated text is rendered as HTML in an internal portal | Schema validation, escaping, grounding checks | After generation, before use |
| Logging gaps | Nobody can show what an agent changed last Tuesday | Signed, append-only ledger with verifiable exports | Across the whole request path |
Almost every control in this table runs outside the model. LLM security is mostly an architecture decision: one path every request has to cross, checks that decide before anything leaves, and a record of each decision.
What changes with AI agent security?
AI agent security is LLM security with write access. The first four risks become more expensive once a model can act, because a successful injection no longer produces a bad paragraph. It produces a sent email or a changed record.
Three controls matter most for agents. Agents should never hold raw credentials: tokens for connected systems stay sealed, and scopes are granted per agent, per tool and per policy. Every action should pass the same AI guardrails as a chat message, plus an approval gate. And separation of duties should apply to agent releases, so the person who built an agent cannot be the one who approves its move to production.
Which classic controls still carry the load?
None of the LLM-specific controls replace the conventional ones; they assume them. An injection detector does not help if a former employee can still sign in, or if an API token carries an administrator's full rights.
- Identity at the front door. Single sign-on through your identity provider, with SCIM provisioning so a person removed there loses access here.
- Roles checked on the server. Hiding a button in the interface is not access control; every administrative request should check the role.
- Scoped tokens. Programmatic access should use tokens limited to an explicit set of scopes, not a person's full rights.
- Encrypted traffic and sealed secrets. HTTPS only, and credentials for connected systems stored sealed, with separate keys per purpose.
Get these wrong and the request-path controls are guarding a door that is already open.
How SphereIQ maps to these risks
SphereIQ puts these controls in its Governance plane, which every model call and agent action passes through:
- Injection and secrets. Prompt-injection detection, direct and indirect, and secret scanning run on every chat message before it reaches a model.
- Personal data. Social security numbers, card numbers, email addresses and phone numbers are masked by content policy; detection is pattern-based.
- Retrieval. Each knowledge source's access rules are applied in the retrieval query, before any passage reaches a model.
- Agents. Actions are scoped MCP tool calls through the Connect MCP hub. Each is validated, scanned, checked against policy, held for approval where required and executed once.
- Providers and deployment. Model calls go only to the providers you enable, SphereIQ does not train models on your data, and it deploys as SphereIQ Cloud (hosted by Sphere), SphereIQ Dedicated (single-tenant, in your own AWS account) or SphereIQ Private (in your own cloud).
- Credentials and records. Connected-system credentials are sealed with AES-256-GCM, and records export as signed newline-delimited JSON whose Ed25519 signature anyone can check offline.
The SphereIQ security page lists each control as built, including the ones marked not yet. SphereIQ is SOC 2 Type II certified.
How to test enterprise LLM security
- Inventory every LLM path. Include assistants, agents, AI features inside existing SaaS and anything else that sends data to a model. Shadow AI is part of the attack surface.
- Plant indirect injections. Put instructions in test documents, tickets and tool responses, and confirm they are caught.
- Seed canaries. Add fake keys and card numbers to test data, then search outbound traffic and logs for them.
- Query as the wrong user. Ask about a restricted source as someone without access. Expect nothing.
- Run a destructive agent action without approval. It should be held, not executed.
- Trace the egress. Confirm every model call, background jobs included, goes where your policy says.
- Ask for the record. Pull the log of one run and verify its integrity without the vendor's help.
Frequently asked questions
What is LLM security?
What are the biggest LLM security risks?
How do you prevent prompt injection in an LLM application?
What is AI agent security?
Does running an LLM in our own cloud make it secure?
Plant an injection in your own documents.
In a walkthrough we run the tests in this article against SphereIQ on your data, from an indirect injection to a held agent write, and show each decision on the ledger.