LLM Security Best Practices for Enterprise Teams

Why LLM Security Is Different

Traditional application security operates on a simple principle: define the valid inputs, validate everything else, and reject anything outside the expected range. SQL injection is defeated by parameterized queries because the database treats user input as data, never as executable code.

LLMs violate this principle by design. Their entire purpose is to interpret natural language — including natural language that looks like instructions — and generate a response. There is no clean separation between "data" and "instructions" in a language model's world. This is what makes LLM security fundamentally harder than traditional application security, and why security teams need a different mental model.

Best Practice 1: Treat the System Prompt as a Security Boundary

The system prompt defines what the LLM is supposed to do, how it should behave, and what it is not allowed to do. It is the first line of defense — but it is a soft boundary, not a hard one. A well-constructed system prompt reduces the attack surface significantly; a poorly constructed one leaves obvious gaps.

System prompt security principles:

• Be explicit about what the model should never do, not just what it should do. "Do not share information from previous conversations" is more secure than hoping the model figures this out.
• Separate the system prompt from user input architecturally. Use the model provider's designated system turn — never concatenate user input into the system prompt string.
• Treat the system prompt as sensitive configuration. Version-control it, review changes, and log which version was active during any given session.
• Do not put secrets in system prompts. Credentials, API keys, and sensitive configuration injected into system prompts can be extracted by adversarial prompting.

Best Practice 2: Defense in Depth Against Prompt Injection

Prompt injection — where malicious instructions are embedded in content the LLM processes — cannot be fully solved at the model level. A defense-in-depth approach uses multiple layers.

Layer 1 — Input filtering:

Screen external content (documents, emails, web pages, database records) for known prompt injection patterns before passing them to the model. This won't catch novel attacks but eliminates a large class of known exploits.

Layer 2 — Context isolation:

Use structured data formats (JSON, XML) when passing retrieved content to the model, with explicit delimiters that distinguish "data to process" from "instructions to follow." Many injection attacks rely on the model treating content as instructions — structural separation reduces this risk.

Layer 3 — Output validation:

Validate agent outputs before executing them. If the agent produces an action instruction as output (tool call, API request), evaluate that instruction against your policy set before executing — regardless of what the model says.

Layer 4 — Infrastructure enforcement:

Even if the model is successfully manipulated, infrastructure-level controls (tool call authorization, action policies) prevent the resulting instructions from executing. An agent that has been prompt-injected into wanting to exfiltrate data cannot do so if its tool calls are evaluated against a "no external data transfer" policy before execution.

Best Practice 3: Implement Least-Privilege Tool Access

The blast radius of any LLM security failure is directly proportional to the tool access the agent has been granted. An agent with access to one read-only database can do limited damage if compromised. An agent with read-write access to file systems, email, databases, and external APIs can do catastrophic damage.

• Grant each agent only the tools required for its specific function — no more
• Scope data access to the minimum records needed (specific database tables, not entire schemas)
• Use short-lived, session-scoped tokens rather than long-lived credentials
• Require explicit authorization for high-risk tool categories (external communications, financial operations, identity management)
• Review and audit tool access grants quarterly — agent requirements change, and unused permissions should be removed

Best Practice 4: Protect Data at the Model Boundary

Every piece of data passed to an LLM as context is potentially exposed — to the model provider's infrastructure, to logging systems, and to adversarial extraction attempts. Protecting sensitive data means controlling what enters the model's context window in the first place.

• PII detection before prompting: Scan all data before including it in a prompt. Redact or pseudonymize personal information that isn't necessary for the task.
• Credential filtering: Automatically detect and block API keys, passwords, and tokens from entering model context — they can be extracted by prompt injection.
• Data minimization: When using RAG, retrieve only the most relevant chunks — not entire documents. The smaller the context window, the smaller the exposure.
• Output DLP: Scan model outputs before delivering them. An agent that has been manipulated into including sensitive data in its response can be caught at the output layer before the data leaves the system.

Best Practice 5: Monitor Behavior, Not Just Logs

Traditional security monitoring looks at logs — access records, error messages, event timestamps. For LLM security, behavioral monitoring is more valuable: patterns of activity that deviate from normal operation, regardless of whether individual log entries look suspicious.

• Establish behavioral baselines: How many tool calls does this agent typically make per session? What data does it normally access? How long do sessions normally run?
• Alert on statistical deviations: An agent making 10x its normal number of external API calls, or accessing data volumes far above baseline, warrants investigation even if each individual action looks authorized.
• Track inter-session patterns: Some attacks unfold slowly across multiple sessions. Correlating behavior over time surfaces threats that session-level monitoring misses.

Best Practice 6: Have an AI-Specific Incident Response Plan

When an LLM security incident occurs, your standard incident response process needs AI-specific adaptations: How do you isolate an agent without breaking dependent workflows? What evidence exists in traces and logs? Is the incident contained to one agent or could other agents with similar configurations be affected?

Run tabletop exercises specifically for AI agent security scenarios before an incident happens. The worst time to figure out your response process is during an active incident.