Guide

What is agentic AI security, and how is it different from LLM security?

Updated November 12, 2026

Short answer

Agentic AI security protects systems where an AI agent acts with tools, credentials and data. LLM security asks what the model says. Agentic security asks what the agent does: which commands it runs, which files it changes, what it sends out. The controls shift from filtering prompts and outputs to limiting access and checking each action before it runs.

What changes when the model gets hands#

An LLM chatbot produces text. A person reads it and decides what to do. The worst case is usually a bad answer or a leaked prompt.

An agent produces actions. It runs shell commands, edits files, calls APIs and pushes code with the credentials of the person who started it. Anything the developer can reach, the agent can reach, usually with no second authorization step.

So the risk moves from what the model says to what the agent does.

How it differs from LLM security#

LLM security is mostly about the input and output of one model call: prompt injection, jailbreaks, sensitive data in responses. Those risks carry over to agents. OWASP now publishes a separate Top 10 for Agentic Applications 2026, a peer-reviewed list of the most critical risks for agentic systems.

Three things are new:

Credentials. The agent acts with real access, so a wrong step has a blast radius.
Untrusted input and privileged action in one step. A repo file, web page or ticket can steer an agent that can also run commands.
Volume. An agent session averages about 145 actions, and long ones pass 1,000. Nobody reviews each one.

That last point breaks the approval prompt. Anthropic says users approve 93% of permission prompts anyway (Anthropic). In its controlled study of 1,053 testers, human review caught just 13.6% of dangerous commands (Anthropic).

The risk classes#

Harden's threat model for AI coding agents has 15 harm classes and 203 threats, organized by harm to the business rather than attack technique. That matters because much of what goes wrong has no attacker at all. The ones security leaders ask about first:

Data disclosure. A credential file gets read and sent out, or secrets get committed.
Destructive change. A database dropped, a force-push over history, files deleted outside the workspace.
Unauthorized access. The agent uses credentials it found to reach systems beyond the task.
Persistence. Hidden instructions in a rules file, a git hook or a cron entry outlive the session. See how agents persist.
Supply chain. A typosquatted package, an unvetted MCP server, or a bad version published outward.
Faked success. The agent deletes the failing test and reports "done." See agents faking test results.
Erosion of oversight. Output grows past what people can review, so approvals become rubber stamps.

Prompt injection cuts across several of these. It's the delivery route; the harm shows up as one of the classes above.

What each control stops and misses#

Start with the conventional controls. They do most of the prevention.

Control	What it stops	What it misses
Least privilege, short-lived scoped credentials	Reach. If the token can't delete backups, the agent can't.	Misuse of access the task legitimately needs
Sandbox	Shell commands reaching beyond its file and network limits	In Claude Code, "The sandbox covers shell commands only. Claude's file tools, MCP servers, and hooks run outside it." (docs)
Permission rules and deny lists	Known commands as typed	The same action written another way: quoting, aliases, encodings
Egress controls	Data sent to hosts you haven't allowed	Leaks through hosts you have allowed
Approval prompts	Some dangerous actions, when someone reads them	Most of them, once people click yes by reflex
Checking each action before it runs	Actions that don't fit what the session is supposed to be doing	A process that's already malicious; exfiltration split across separate calls
Records of every decision	Nothing by themselves	Nothing; they're how you answer an auditor or rebuild an incident

The action check is the one LLM security has no equivalent for. The same command can be fine under one intent and harmful under another, so the check has to know the session's intent. For how the Claude Code layers stack, see permissions vs hooks vs sandbox.

A short checklist#

Inventory which agents run on which machines, and who owns each.
Give agents narrowly scoped credentials, never a developer's admin token.
Make agent config and rules files read-only and watch them for changes.
Run unattended work in a sandbox or container.
Gate the small set of irreversible actions: publish, shared push, deploy, external email. See irreversible actions to gate.
Check actions before execution, not only after.
Start watch-only, read the records, then enforce.
Treat CI and unattended sessions as the weak point, because nobody's there to click.

Why coding agents come first#

Most enterprises meet agentic AI through coding agents. They're adopted bottom-up, they sit on developer laptops with real credentials, and they run shell, file and git actions all day. For a practical starting point, see securing agents on developer laptops.

Where Harden fits#

Harden Agentic Integrity Foundation (AIF) runs on the developer laptop, outside the agent, at the agent's pre-execution hook. Every command, file edit and push is checked against the session's intent before it runs, in about 28 ms, decided locally. Nothing leaves the machine.

One policy covers every agent that exposes a hook, and it starts watch-only. It's a layer, not a perimeter: it doesn't replace least privilege, scoped credentials or egress policy.

FAQ