What is AI agent security?
AI agent security is the set of controls that decides what an AI agent may do with the access it holds. An AI agent is a program in which a language model chooses the next step: which tool to call, with which arguments, on whose behalf. The agent then carries out that step with real credentials against real systems, such as a customer relationship management (CRM) system, a billing API, a code repository or an inbox.
That moves the risk. A chatbot that gets something wrong produces a bad paragraph. An agent that gets something wrong issues a refund, deletes a record or emails a customer list to the wrong address. In agent security, the risk is in the action, not the answer.
A working program answers six questions for every agent:
- Is it on our list, and who owns it?
- Can it prove who it is, and whom it acts for?
- Is this specific call allowed, with these arguments, on this record, within these limits?
- What sensitive data goes in and comes out?
- If it is hijacked, how far can the damage reach?
- Can we prove afterward what happened?
Whether your team calls it agent security or agentic AI security, this guide answers those questions in turn, for security architects, platform leads and chief information security officers (CISOs).
Why agent security differs from LLM and application security
Application security assumes the code decides: a developer writes the path from request to database, and reviewers read it before it ships. Large language model (LLM) security mostly focuses on the model's text: jailbreaks, harmful content and leaks in answers.
Agents break both assumptions. A model that reads untrusted text chooses the path at runtime, and its output is a tool call that runs.
| Traditional application | LLM chat assistant | AI agent | |
|---|---|---|---|
| Who chooses the action | Code, written and reviewed in advance | Nobody; it returns text | A model, at runtime, for each step |
| What it acts with | A service account scoped to known code paths | Usually nothing beyond the chat | Credentials and tools, often a user's token or a shared key |
| Typical failure | A bug or injection in a known path | A wrong or harmful answer | A permitted tool used for the wrong amount, record or recipient |
| Where controls must sit | In the code and the service | On model input and output | Outside the model, at each action and data flow |
The last row is the practical lesson. Instructions in a system prompt are requests, not rules. The OWASP (Open Worldwide Application Security Project) entry on LLM06:2025 Excessive Agency draws the same conclusion: enforce authorization in downstream systems instead of relying on the model to decide.
The AI agent attack surface
Every agent has six surfaces that an attacker, or an honest mistake, can use. Map each one before you choose tools.
- Inputs. Prompts, tickets, emails, documents, web pages and tool results. Any text the agent reads can carry instructions. That is indirect prompt injection: the attacker leaves a note where the agent will read it.
- Tools. Application programming interfaces (APIs) and Model Context Protocol (MCP) servers. Each tool is a capability, and each tool description is text the model reads, so a malicious MCP server can steer the agent.
- Identity. A shared API key, a user's OAuth token or a cloud role. The identity sets the ceiling on what any single mistake can do.
- Data. What the agent can read, and where it can send it: model providers, email, chat, files and other services.
- Runtime. Coding and data agents execute code they wrote or downloaded, often on a laptop or build host with secrets in reach.
- Other agents and memory. Messages from other agents, shared memory and retrieval stores. Anything that persists can carry a poisoned instruction into a later task.
A useful threat model for one agent fits on a page: one line per surface, the worst plausible outcome, and the control that bounds it.
Why prompt filters are not a security boundary
Most teams start with defenses inside the model's context: a firm system prompt and filters on input and output. Keep them; they stop noisy attacks. They are not a boundary, for three reasons.
First, the model treats everything in its context as a possible instruction, and no filter recognizes every phrasing, language or encoding. Attackers hide text in HTML comments, base64 or invisible fonts. OWASP's entry on LLM01:2025 Prompt Injection says it is unclear whether fool-proof prevention exists.
Second, a filter sees text, not consequences. "Refund invoice 8812" is routine or theft depending on who owns the invoice and how much has already gone back this week. Only something that can read the invoice can tell.
Third, the agent is rarely the only caller. The same billing API is reached by a vendor's agent, a developer's coding agent and next quarter's project. Checks built into one agent protect only that agent.
So design on the assumption that an agent will sometimes be wrong or hijacked, and make sure the damage stays small. The OWASP AI Agent Security Cheat Sheet takes the same line: authorization runs outside the agent, and unknown tools fail closed.
Threats to AI agents and the controls that stop them
Use this table to turn a threat model into a control list. Most rows assume the attack on the model succeeded, and limit what happens next.
| Threat | Example | Control that bounds it | Guide |
|---|---|---|---|
| Indirect prompt injection | A partner document hides an instruction in an HTML comment | Decode and inspect inputs; hold suspicious documents | Data protection |
| Excessive permissions | A triage agent's CRM key can delete customers | Default deny; grants per agent and operation | Authorization |
| Argument abuse | A refund tool is called with $4,500, not $45 | Argument conditions; budgets per record and period | Spending limits |
| Wrong record | A refund on another customer's invoice | Read the record and check ownership first | Authorization |
| Shared or stolen credentials | Five agents share one API key, and it leaks | One short-lived identity per agent; gateway holds service keys | Identity |
| Confused deputy | An assistant acting for one employee edits a colleague's cases | Check whom the agent acts for on every call | Identity |
| Data exfiltration | The agent emails the customer list to a personal address | Outbound inspection with a policy per destination | Data protection |
| Malicious or changed tools | An MCP server adds a tool or rewrites a description | New tools stay closed until an owner approves | MCP security |
| Attacker-controlled code | A poisoned dependency runs inside a coding agent | Sandbox with no network and no credentials | Sandboxing |
| Manipulated approvals | An agent writes a persuasive reason for a risky change | Approver sees the exact call; requester cannot approve | Human approval |
| Shadow agents | A finance script sends spreadsheets to a public model | Discovery from evidence, not surveys | Discovery |
| No evidence | Nobody knows which agent changed a record | A tamper-evident receipt per decision | Audit |
The six controls of a mature agent security program
Mature programs converge on six controls, one for each question in the first section. You need all six, because each covers a gap the others leave. Authorization cannot see a hidden instruction in a document, and data protection cannot tell that a refund is too large.
1. Discovery and inventory
You cannot protect an agent you do not know about. Agents arrive one team at a time: built on a software-as-a-service (SaaS) platform, shipped in a container, or run as a script on a workstation. Surveys find the agents people remember.
Agents leave evidence in five places: where they are defined (agent platforms), where they get their model (model API calls and logs), where they get their permissions (the identity provider and cloud identity and access management), where they are built (code repositories) and where they run (cloud accounts, clusters and hosts). Correlating these separates "something called a model" from "this process runs an agent loop that calls tools".
What good looks like:
- One entry per agent, with its owner, where it runs, the model it uses, its identities and the tools it reaches.
- A clear split between agents that act and AI features that only answer.
- Flags for no owner, shared credentials, broad access and shadow AI.
- New agents detected within days, not at the next audit.
Read more in discovering AI agents and shadow AI and how to find the AI agents at work in your business.
2. Identity and ownership
Each agent needs a name it can prove and a person who answers for it. With a shared API key, logs cannot say which agent acted, and revoking the key stops them all.
Use the identity an agent already has when it is strong: a cloud role, a Kubernetes service account federated to your identity provider, or a workload identity from SPIFFE (Secure Production Identity Framework for Everyone), whose identity documents are short-lived. When an agent acts for a person, record both. OAuth 2.0 Token Exchange (RFC 8693) separates delegation, where the agent keeps its own identity and acts for the user, from impersonation, where it becomes indistinguishable from the user. Prefer delegation: it keeps the agent visible in every log.
What good looks like:
- Every agent that acts has its own identity and a named owner.
- No long-lived shared keys; credentials rotate without human steps.
- Every request carries both the agent and the person it acts for.
- An agent with no owner gets no credentials.
See AI agent identity.
3. Authorization of each action
Access control usually answers "can this agent reach this system?" Agents need a finer question: should this call, with these arguments, on this record, for this person, happen now? A complete check covers five things:
- Operation. Grants per agent and per operation, deny by default, and explicit forbids that always win.
- Arguments. Amount, recipient, destination, query scope.
- Record. Read the target record, such as an invoice's customer or a case's queue, and confirm it belongs to the task.
- Budgets. Limits per call, per record and per period, for example $2,000 per invoice per week.
- Approvals. Above a threshold, a named person approves the exact call. The person the agent acts for cannot approve it. An approval runs once.
This control does the most to shrink the blast radius, because it holds even when the model is fooled.
What good looks like: decisions are made outside the agent; the enforcement point, not the agent, holds the service credentials; new tools stay closed until an owner approves them; unused grants are removed on a schedule.
Go deeper with AI agent authorization, spending limits for agents, human approval of agent actions and MCP security.
4. Data protection in both directions
Inbound content can carry personal data, secrets or hidden instructions. Outbound text goes to model providers, email, chat and other services.
Data loss prevention (DLP) for agents works on each call, not on files at rest. Decode first, because attackers hide text behind HTML entities, percent-encoding or base64. Then let deterministic rules find secrets, one-time codes and personal data, and confirm card and bank numbers with their checksums. Use a classifier only for questions rules cannot answer, such as whether a document is trying to instruct the agent.
Then one policy decides what each kind of data may do at each destination. A customer's email address may go into a reply to that customer, but not to a public model. An API key goes nowhere.
What good looks like:
- Secrets and sign-in codes never reach a model provider or an outside address.
- Personal values sent to a model travel as placeholders and are restored in the answer.
- Documents with hidden instructions are held for review before the agent reads them.
- Bulk exports stop even when the agent is allowed to send email.
See data loss prevention for AI agents.
5. Isolation of code execution
Coding and data-analysis agents run code. Assume some of it belongs to an attacker: a poisoned dependency, a script copied from a web page, or a command a document suggested. A sandbox should leave that code with nothing to use:
- No network by default. The only way out is a broker that inspects each request.
- No credentials inside. The broker adds them on the way out, scoped to one call.
- A read-only root file system and access limited to the task's workspace, for example with Linux Landlock rules.
- An unprivileged user with no capabilities, and a seccomp filter that blocks mounting, kernel modules and BPF.
- Memory and process caps, so a fork bomb stops at a limit.
- One sandbox per task, discarded afterward.
Containers share the host kernel; microVMs add a hardware-virtualization boundary at some cost in start time. For untrusted code, layers matter more than speed.
What good looks like: remote code execution inside the sandbox has no effect outside it. See AI agent sandboxing.
6. Audit evidence
After an incident you need four answers fast: which agent, acting for whom, under which grant, and with what result. Application logs rarely give all four. The service sees a shared key, and the agent framework logs prompts, not decisions.
Record every decision, allowed and denied: the agent, the person it acted for, the operation and target, the deciding policy, the outcome and any approval. Record what was found and done, not the sensitive values. Chain entries with hashes so a missing or edited entry shows, keep them in your own environment, and alert on delivery gaps.
What good looks like:
- Any agent action traces to an owner and a grant in minutes.
- Denied calls are as visible as allowed ones.
- Records survive the compromise of the agent that produced them.
See audit trails for AI agents.
Where to enforce agent security controls
The same check can run in several places. Where it runs decides what it can see and whether a hijacked agent can go around it.
| Enforcement point | What it sees | Strength | Weakness | Best for |
|---|---|---|---|---|
| Inside the agent (framework hooks) | The model's plan and tool choices | Rich context; easy for builders | Covers one agent; gone if its code is compromised | Early warnings |
| Model gateway | Prompts and completions | One place for all model traffic | Blind to calls to your services | Masking data sent to model providers |
| In front of the service (API or MCP gateway, last hop) | Every call to the service, from any agent | Covers every caller; holds credentials; can fail closed | Needs a traffic path; must read records | Authorization, budgets, approvals, response masking |
| Runtime sandbox and broker | Processes, system calls, network attempts | Contains code the agent runs | No business context | Code-executing agents |
| Inside the service | Its own data model | Most precise | Each team builds it separately | Core systems, over time |
The rule of thumb: put each decision where the agent cannot go around it. For actions on your systems, that is in front of the service: the gateway holds the credentials, and the network lets agents reach only the gateway. Keep in-agent checks as an early warning, and use a sandbox wherever an agent runs code.
Working with the API gateway you already run
You do not need to replace your API gateway. With Envoy or Istio, Envoy's external authorization filter can ask a separate service to decide each request. Set failure_mode_allow to false, so an outage of the decision service denies calls instead of allowing them. Behind Kong, Apigee or a cloud API gateway, an agent-aware check can run as the last hop before the service.
As of October 2026, the MCP authorization specification makes authorization optional. When it is used, MCP servers must accept only tokens issued for them and must not pass other tokens through. Check every MCP server you depend on for both.
The longer argument is in keep your API gateway.
Worked example: securing a refund agent at Northwind
Northwind is an illustrative company used in AgentFort's recorded demonstrations. Its support team gives an agent a refund tool. The agent acts for Priya, a support lead.
Every existing check says yes to any refund: the agent may call the billing API, and the key works. The billing owner wants five answers before money moves. May this agent refund at all? Is the amount within limits? Does the invoice belong to the customer on the case? Who approves large refunds? Can we prove it later?
The rules, written the way finance says them
The billing owner writes four rules: refunds up to $100 run without approval; larger refunds need Finance, and the person the agent acts for cannot approve; at most $2,000 per invoice per week; and the invoice must belong to the customer on the case. Expressed in Cedar, an open policy language that denies by default and lets any forbid override a permit, they look like this (illustrative):
// Small refunds run on their own
permit (principal in Team::"support-agents", action == Action::"billing.createRefund", resource is Invoice)
when { resource.customer == context.caseCustomer && context.amount <= 100 };
// Larger refunds need Finance, never the person the agent acts for
permit (principal in Team::"support-agents", action == Action::"billing.createRefund", resource is Invoice)
when {
resource.customer == context.caseCustomer &&
context has approver &&
context.approver in Team::"finance" &&
context.approver != context.actingFor
};
// The weekly cap per invoice beats any approval
forbid (principal, action == Action::"billing.createRefund", resource is Invoice)
when { context.refundedThisWeek + context.amount > 2000 };
Cedar judges each request on its own, so the enforcement point supplies the running weekly total and reads the invoice to fill in its customer. Open Policy Agent's Rego can express the same rules.
What happened to four refund requests
| Request | Outcome | Why |
|---|---|---|
| $40 on the customer's invoice | Runs | Under the $100 threshold |
| $450 on the same invoice | Held for Dana in Finance; runs once after approval; a repeat is held again | Over $100; Priya cannot approve because the agent acts for her |
| $4,500 | Blocked | Over $2,000 per invoice per week |
| A refund on another customer's invoice | Denied | The invoice was read first, and it belongs to someone else |
The agent gets a short reason and a receipt number, never the rule or the invoice data. The full story is in how to stop an AI agent issuing a $4,500 refund.
One limit: policy cannot judge whether a customer deserves a $90 refund. An agent talked into many small, permitted refunds stays inside every rule. Catch that with budgets per customer and period, and by reviewing receipts for patterns, as finance does for human refunds.
A 30/60/90-day rollout plan for AI agent security
This sequence gets visibility first, then puts the strongest controls on the riskiest actions.
Days 1–30: find the agents and their owners
- Pull agent lists from every agent platform you use, and from cloud model logs.
- Search code repositories for agent frameworks and model software development kits (SDKs).
- Assign an owner to every agent that acts.
- List every credential an agent uses, and mark the shared ones.
- Pick the 3 riskiest agents: those that move money, change customer records or touch regulated data.
Exit criterion: an inventory that security, IT and compliance agree on.
Days 31–60: control the riskiest actions
- Give those 3 agents their own identities and retire their shared keys.
- Put an enforcement point in front of the services they call, and move the service credentials there.
- Write default-deny grants per operation, with argument conditions, record checks, budgets and approval thresholds.
- Replay a week of real calls against the new rules before you enforce them.
- Mask personal data and block secrets in traffic to model providers.
Exit criterion: the riskiest actions are decided outside the agent, and every decision leaves a record.
Days 61–90: contain and make it routine
- Move code-executing agents into sandboxes, and remove credentials from their hosts.
- Make the audit trail tamper-evident and send alerts to your security operations center.
- Test agents against the OWASP agentic top 10.
- Publish an onboarding path: a new agent gets an identity, an owner and grants before production.
- Compare grants with actual use, and remove what is never used.
Track six numbers from day 1: agents with an owner, agents with their own identity, shared credentials left, high-risk operations behind enforcement, median approval time and denied calls per week.
AI agent security maturity model
Place each control separately. Most organizations sit at different levels for different controls.
| Control | Level 1: ad hoc | Level 2: managed | Level 3: enforced |
|---|---|---|---|
| Discovery | Survey or spreadsheet | Connectors to platforms and logs; owners assigned | Continuous and evidence-based; new agents flagged within days |
| Identity | Shared keys and borrowed user tokens | Own identity for the riskiest agents | Every acting agent has a short-lived identity and an owner; delegation recorded |
| Authorization | Agents hold service keys with broad scopes | Per-operation grants on high-risk services | Default deny; arguments, records, budgets and approvals checked outside the agent |
| Data protection | Filters on the chat window | Masking on traffic to model providers | Both directions on every call, decoded first, with a policy per destination |
| Isolation | Agents run on shared hosts with credentials in reach | One container per agent | One sandbox per task, no network, credentials added by a broker |
| Audit | Application logs | Central log of agent tool calls | A tamper-evident receipt per decision, kept in your environment |
AI agent security checklist
- Inventory every agent that can act, including vendor, SaaS and coding agents.
- Assign a named owner to each agent, and deny credentials to agents without one.
- Replace shared API keys with one identity per agent, and record whom it acts for.
- Take service credentials away from agents, and hold them at the enforcement point.
- Deny by default, and grant per agent and per operation.
- Check arguments, target records and budgets, not only access.
- Route high-impact calls to an approver who is not the requester.
- Keep new and changed tools closed until an owner reviews them.
- Inspect inbound content for hidden instructions and outbound content for secrets and personal data.
- Run code-executing agents in a sandbox with no network and no credentials.
- Keep a tamper-evident receipt for every decision, including denials.
- Make the enforcement point fail closed when the policy service is down.
- Test each agent against the OWASP agentic risks before every major release.
How the OWASP Top 10 for Agentic Applications maps to these controls
The OWASP GenAI Security Project published the OWASP Top 10 for Agentic Applications for 2026 on December 9, 2025, with input from more than 100 experts. It names risks; the six controls above reduce them.
- ASI01 Agent Goal Hijack: inbound inspection, plus authorization on every resulting action.
- ASI02 Tool Misuse and Exploitation: per-operation grants, argument checks and budgets.
- ASI03 Identity and Privilege Abuse: one identity per agent, delegation instead of impersonation, no shared keys.
- ASI04 Agentic Supply Chain Vulnerabilities: tool registration and approval, discovery, sandboxing.
- ASI05 Unexpected Code Execution (RCE): sandboxing with no network and no credentials.
- ASI06 Memory and Context Poisoning: inspection before content is stored, memory scoped per user or task.
- ASI07 Insecure Inter-Agent Communication: mutual authentication and authorization between agents.
- ASI08 Cascading Failures: budgets, rate limits, failing closed.
- ASI09 Human-Agent Trust Exploitation: approvals of the exact call, separation of duties.
- ASI10 Rogue Agents: least privilege, behavior review against grants, fast revocation.
For each risk's examples, tests and enforcement points, see OWASP agentic top 10: controls and tests.
What these controls do not cover
Be clear with stakeholders about the limits.
- Correctness inside the rules. An agent can take a permitted action for a bad reason. Budgets cap the cost; they do not make the decision right.
- Model quality. Poisoned training data, bias and hallucination are model risks. Runtime controls limit their effects but do not fix them.
- Agents with no traffic path. An assistant acting entirely inside a SaaS platform, or on a personal device, may be discoverable but not enforceable by you. There you rely on the platform's controls.
- Human judgment. An approver who clicks through every request is not a control.
- Friction. Every hold costs someone time. Tune thresholds with real data, or teams will route around the controls.
Choosing AI agent security tools
Most tools cover one or two of the six controls. Discovery and posture tools build the inventory. Non-human identity tools govern credentials. MCP and API gateways decide calls. AI gateways sit between applications and model providers. Sandboxes contain code. DLP inspects content. Map each candidate against the six controls and the enforcement table before you compare features. The AI agent security tools guide covers each category and its gaps, and the agent security glossary defines the terms used here.
How AgentFort handles AI agent security
AgentFort is security for AI agents. Its five controls map to the six in this guide. AgentFort Discover finds agents through read-only connectors and an optional sensor. AgentFort Identity uses an agent's existing identity or issues a SPIFFE identity, and gives each agent an owner. AgentFort Access sits between agents and services over REST and MCP, and checks the operation, arguments, record, acting-for, budget and approvals of every call. AgentFort Data Protection inspects calls in both directions. AgentFort Isolation runs each task in its own sandbox built from Linux kernel features. Visibility keeps a chained receipt for every request.
Enforcement runs on your side, alongside your existing gateway and identity provider. All five controls run end to end in a lab against Northwind, a simulated company. Watch the demos or apply as a design partner.
Frequently asked questions
Is agentic AI security the same as AI agent security?
In practice, yes. Both terms cover securing software in which a language model plans steps and calls tools with real credentials. Writers who say agentic AI security often put more weight on multi-step planning, memory and systems of several cooperating agents. The controls are the same: an inventory, an identity per agent, a check on every action, data protection in both directions, isolation for code execution, and an audit trail.
How is AI agent security different from non-human identity management?
Non-human identity (NHI) management governs credentials for software: service accounts, API keys, tokens and certificates, and how they are issued, rotated and revoked. AI agent security needs that, but it goes further. An agent's behavior is chosen at runtime by a model, so a valid credential is not enough. You also need per-call decisions on arguments and records, data inspection, sandboxing for code, and evidence of each action.
Who should own AI agent security in a company?
Split it. The security team owns the policy framework, the enforcement points and the audit trail. Each agent has a named business owner who answers for what it does. Each service has an owner who approves which operations agents may call and with what limits. Platform or IAM teams run identity. Without named owners at all three levels, agents tend to inherit broad access by default.
How do I secure AI agents built in SaaS platforms like Copilot Studio or Agentforce?
Start with the platform's own admin view or API to list the agents, their owners and the connectors and credentials each one uses. Scope each agent's run-as identity as tightly as the platform allows. Where the agent calls your own APIs, put authorization in front of those APIs. Where it acts only inside the platform, you depend on the platform's permission model, so review it like any privileged integration.
Does AI agent security slow agents down?
Deterministic policy checks add little. In AgentFort's lab, its gateway added about 1 ms at the 95th percentile at 100 requests per second. Language classifiers cost more, and human approvals cost minutes or hours. So reserve classifiers for content that needs a judgment of meaning, and approvals for the small share of actions that move money or send data out of the company. Measure latency on your own traffic before you commit.
How do I secure coding agents that run on developer laptops?
Treat the code they run as untrusted. Run commands in a sandbox with no network by default and no access to the home directory, SSH keys or cloud credentials. Route outbound requests through a proxy that scans for secrets. Require explicit consent before adding a local MCP server, and show the full command it will run. Give the agent its own short-lived credentials instead of the developer's long-lived ones.