In short
LLM security protects a model and its inputs and outputs: prompt injection, jailbreaks, data leakage in responses, model theft and harmful content. AI agent security starts where the answer ends — it governs identity, tool calls, memory, autonomy and blast radius. An LLM can produce a bad sentence; an agent can execute a bad action.
Definition
LLM security treats the model as the asset. Its questions are: can an attacker manipulate the input, extract training data, steal the model, or elicit prohibited output? Its controls are input handling, output filtering, rate limiting, evaluation and model access control.
AI agent security treats the action as the asset. Its questions are: what can this agent do, with whose credentials, against which systems, and can we see, gate and reverse it? Its controls are identity, authorization, tool allow-listing, memory policy, tracing and containment.
The two are complementary and neither substitutes for the other. Hardening a model without bounding its capability leaves an authorized path to damage; bounding capability without model-level defenses leaves the agent easy to steer inside its bounds.
Security risks
Assuming filters equal safety
Teams frequently deploy prompt filtering and consider agent risk handled, while the agent still holds standing credentials to production systems.
Evaluating the model, not the system
Model benchmarks say nothing about tool scope, memory hygiene or approval gates, which is where agent incidents actually occur.
Splitting ownership
Data science owns the model, platform owns the tools, IAM owns the credentials, and nobody owns the agent as a whole.
Ignoring persistence
LLM threat models are usually per-request. Agents carry memory and long-lived identity across sessions.
Missing the creation layer
Neither classical model security nor per-agent runtime monitoring accounts for the AI Principals that spawn and train agents.
Untraceable multi-step failures
A safe individual response can still be part of an unsafe plan, which only full trace review surfaces.
Examples
Same injection, different outcome
A chat-only assistant tricked into revealing its system prompt is embarrassing. The same injection against an agent with a payments tool is a financial loss.
Output filter passes, action fails
The agent's response text is entirely benign while its tool call quietly changed an IAM policy.
Model swap without review
A team upgrades the underlying model. Tool scope and credentials remain unchanged and unreviewed, and behaviour shifts.
Session-safe, memory-unsafe
Each conversation passes safety checks, but a poisoned memory entry from last month keeps steering decisions.
Architecture
Model layer (LLM security)
Model access control, input handling, output filtering, evaluation, artifact integrity and abuse rate limiting.
Agent layer (agent security)
Identity, entitlements, tool broker, memory policy, planning constraints and action approval.
Shared trust boundary
The rule that retrieved content is data, never instruction, must hold in both layers.
Unified observability
One trace spanning prompt, plan, model output, tool call and result — otherwise investigations stall at the boundary.
Creation layer
Above both: the Principals that create agents and train models, requiring their own controls.
Controls
Do both, in this order
Start with capability limits — they cap damage. Then add model-level hardening to reduce how often incidents start.
Assign single ownership for the agent
One accountable owner covering the model, the credentials, the tools and the data the agent touches.
Threat-model per action, not per prompt
Enumerate the agent's possible actions and rank them by reversibility and business impact.
Re-review on model change
Treat a model version change as a change to the security posture of every agent that uses it.
Trace across layers
Correlate model calls with tool calls and identity events so behaviour can be reconstructed end to end.
Comparison
| Dimension | LLM security | AI agent security |
|---|---|---|
| Primary asset | The model and its output | The action and its consequence |
| Typical threat | Prompt injection, jailbreak, data extraction | Unauthorized action, over-privilege, tool abuse |
| Identity involved | Usually the caller's | The agent's own non-human identity |
| Persistence | Per request | Memory and long-lived credentials |
| Key controls | Input/output handling, evaluation | Least privilege, tool allow-list, approval gates |
| Worst case | Harmful or leaked content | Money moved, data exfiltrated, systems changed |
Frequently asked questions
If I secure the LLM, am I covered?
No. Model-level defenses reduce manipulation attempts but do not limit what the agent may do once it acts. Authorization and containment are separate controls.
Which should we implement first?
Capability limits. Reducing standing privilege and gating irreversible actions lowers worst-case impact immediately, even before model hardening matures.
Do OWASP's LLM risks still apply to agents?
Yes, and OWASP has extended them with agent-specific threats such as tool misuse, memory poisoning and privilege compromise.
Who should own agent security?
A named owner per agent, with platform security providing the enforcement layer — not a split across three teams with no accountable party.
Sources
How Andeavour addresses it
Coverage across both layers
AgentGuard governs identity, tools and actions while integrating the model-level signals that indicate manipulation.
One trace, end to end
Prompt, plan, tool call and identity event are correlated so investigations do not stop at the model boundary.
Principal-aware policy
Policy follows the creation lineage, so a model or template change is evaluated across every agent it affects.
See it against your own environment
A 30-minute technical session with the Andeavour team — no integration required to start.