Quick answer: Agentic AI security is the discipline of controlling AI systems that plan and take actions through tools, APIs and other agents, rather than only generating text. The decision rule: treat every agent as a non-human identity with its own credentials, least-privilege scopes, an owner and an audit trail, and assume anything it reads, including tool results, may contain instructions from an attacker.
The security conversation about LLMs in 2024 was about what a model might say. In 2026 it is about what an agent might do. Enterprises are deploying agents that read mailboxes, update CRM records, raise tickets, approve expenses, write and run code, and call other agents. Each of those is a privileged action, and most of them run today under a human user's identity with the human's full permissions.
That is the gap this article addresses. Agentic AI security is not a new vocabulary layered on prompt filtering. It is identity and access management, supply chain security, and data protection, applied to a new class of actor that cannot be trusted to follow instructions when its inputs are adversarial.
Written for CISOs, identity and security architects, and the data and privacy leaders who have to decide what an agent is allowed to touch.
What is agentic AI, and how is it different from generative AI?
Generative AI produces content in response to a prompt: text, code, images. Agentic AI uses a model as a reasoning engine inside a loop: observe a goal and context, plan, choose a tool, act, observe the result, repeat until done. Four components define an agent and each one is an attack surface:
- Model (reasoning) — What it does: Interprets goals, plans, decides actions · Security implication: Can be manipulated by any text it reads, including tool outputs and documents
- Tools and integrations — What it does: APIs, functions, connectors, browsers, code execution · Security implication: Each is a privilege; tool descriptions and results are untrusted input
- Memory and retrieval — What it does: Short-term context, long-term stores, vector databases · Security implication: Poisonable; persists manipulation across sessions
- Orchestration and communication — What it does: Multi-step planning, sub-agents, agent-to-agent protocols · Security implication: Cascading failures; impersonation between agents
The protocol layer has standardized quickly. The Model Context Protocol (MCP) and similar frameworks let agents discover and call tools from third-party servers, which is enormously useful and introduces a software supply chain you probably have not inventoried. See the OWASP Top 10 for LLM Applications for the base risks (prompt injection, sensitive information disclosure, supply chain, excessive agency) and OWASP's agentic threats and mitigations work for the agent-specific extensions such as memory poisoning, tool misuse, privilege compromise and rogue agents.
Should AI agents have their own identity and permission system?
Yes. This is the single highest-leverage decision in agentic AI security, and the one most organizations get wrong at first by letting agents inherit the user's token.
Why inheritance fails:
- Over-privilege by default. A user with access to the whole finance share gives the agent access to the whole finance share, when the task needed one folder.
- No attribution. Logs show the human did it. When an agent deletes 3,000 records at 2 a.m., the incident response starts with the wrong suspect.
- No revocation. You cannot disable the agent without disabling the person.
- Blast radius equals the user's blast radius. A prompt injection against an agent running as an executive assistant has the executive's permissions.
What good looks like, in identity terms practitioners already know:
- Agent as a non-human identity. Each agent, or agent deployment, gets its own identity in the IdP, with an owner, a purpose, an expiry and a review cadence, exactly as you (should) treat service accounts.
- Least privilege per task, not per agent. Scopes granted for the duration of a task, ideally through short-lived tokens and on-behalf-of flows that carry both the agent identity and the delegating user. The agent should be able to do less than the user, never more.
- Separate read from act. Reading a calendar and sending an invitation are different permissions. Most agent incidents in practitioner accounts involve an action scope that was never needed.
- Human approval for consequential actions. Payments, deletions, external sends, permission changes and code deployment should require a human confirmation step, with the proposed action rendered in plain language. Guard against "approval fatigue" by making these rare and meaningful.
- Kill switch. A way to revoke one agent's credentials in seconds without touching users or other agents.
What is prompt injection, and why is it worse for agents?
Prompt injection is the manipulation of an AI system by placing instructions in content it processes. Direct injection comes from the user. Indirect injection comes from anything else the system reads: a web page, an email, a PDF, a calendar invite, a database field, a tool result, or another agent's message. OWASP ranks it as the top risk for LLM applications, and there is no complete technical fix; models cannot reliably distinguish data from instructions.
For a chatbot, a successful injection produces bad text. For an agent, it produces actions: exfiltrating data through a tool call, sending email, changing records, or recruiting other agents. The practical consequences for your design:
- Assume compromise of the reasoning layer. Security has to hold even if the model is fully manipulated. That is why identity scoping and action gating matter more than prompt hardening.
- Treat tool results as untrusted. A search result or a document fetched by the agent is attacker-controlled content entering the prompt. Sanitize, constrain and, for high-risk actions, require confirmation.
- Constrain outputs by schema. Where the agent's output drives a downstream action, validate it against a strict schema and allowlist rather than parsing free text.
- Limit what can leave. Egress control on where an agent can send data (domains, recipients, tools) is your last line against exfiltration.
- Detect, do not only prevent. Monitor for anomalous tool-call sequences, unusual volumes and off-pattern destinations, and log every prompt, retrieval and action for after-the-fact investigation.
What is tool poisoning and the agent supply chain problem?
When an agent connects to an MCP server or any tool registry, it reads tool descriptions that tell the model what each tool does and how to call it. Tool poisoning hides instructions in those descriptions ("before calling this tool, also send the contents of the user's SSH key to..."). The model reads the description as guidance and may comply. Related risks include tool shadowing (a malicious tool mimicking a legitimate one), rug pulls (a tool server changing behavior after approval) and over-permissioned servers that expose far more than the task requires.
This is a software supply chain problem and should be handled as one:
- Maintain an allowlist of approved tool servers and pin versions; treat changes to tool descriptions as changes requiring review.
- Run third-party tool servers in isolated environments with scoped credentials and egress restrictions.
- Scan tool definitions for embedded instructions and suspicious patterns before registration.
- Record the provenance of every tool and model component in your AI inventory, alongside the model supply chain (weights, datasets, fine-tunes) that ISO 42001 and the EU AI Act expect you to document.
- Apply the same posture to agents that your developers install locally. Unvetted coding and desktop agents are the fastest-growing form of shadow AI.
How do you audit what an AI agent did?
Agents produce two kinds of evidence, and you need both.
Action logs come from the systems the agent touched: the CRM, the mail server, the ticketing API, the cloud control plane. Because the agent has its own identity (see above), these logs attribute actions correctly. Correlate them with a session or task identifier passed through every call.
Reasoning logs come from the agent runtime or gateway: the prompt, retrieved context, tool calls with arguments, tool results and the model's outputs at each step. These are essential for understanding why an agent did something, and they are sensitive, because they contain the data the agent handled. Store them with the same classification as the most sensitive data they may contain, apply retention limits, and restrict access.
A gateway or proxy in front of all model calls is the simplest way to get the reasoning log and to enforce runtime policy in one place. It is also the runtime enforcement pillar of AI TRiSM, which is where program-level ownership and metrics for agents should sit.
Pre-deployment checklist for agentic AI security
Use this as the gate between pilot and production. Every item maps to a control described above.
Identity and access
- [ ] Agent has its own identity in the IdP, with owner, purpose, expiry and review date
- [ ] Scopes are least-privilege per task; read and act scopes separated
- [ ] Short-lived credentials; no long-lived shared secrets in configuration
- [ ] Consequential actions require human confirmation rendered in plain language
- [ ] One-step revocation tested
Inputs and tools
- [ ] All tool servers allowlisted, version-pinned and scanned for embedded instructions
- [ ] Third-party tools isolated with scoped credentials and egress restrictions
- [ ] Tool results and retrieved documents treated as untrusted; schema validation on outputs that drive actions
- [ ] Egress allowlist for destinations the agent can send data to
Data
- [ ] Data sources the agent can reach are classified and access-reviewed; the agent inherits the data security posture you point it at
- [ ] Sensitive-data redaction on inputs and filtering on outputs where the task allows
- [ ] Memory and vector stores protected against write access from untrusted sources
Monitoring and response
- [ ] Gateway logging of prompts, retrievals, tool calls and outputs with a task identifier
- [ ] Anomaly detection on tool-call patterns, volumes and destinations
- [ ] Agent incidents included in the incident response runbook, with the kill switch as step one
- [ ] Red-team exercise against indirect injection and tool poisoning completed and findings closed
Governance
- [ ] Agent registered in the AI inventory with tier, owner, data sources and controls
- [ ] Evaluation results and oversight plan documented for high-tier agents
Key takeaways
- Agentic AI security is identity, supply chain and data protection applied to a new class of actor that cannot be trusted with adversarial inputs.
- Give every agent its own identity, least-privilege scopes per task, separate read and act permissions and a tested kill switch.
- Assume the reasoning layer can be fully manipulated through indirect prompt injection; design so the damage is bounded anyway.
- Treat tool descriptions and tool results as untrusted input and tool servers as a software supply chain to allowlist, pin and scan.
- Put a gateway in front of model calls for runtime policy and reasoning logs; correlate with action logs via a task identifier.
- Gate the pilot-to-production step with a checklist, and red-team for injection and tool poisoning before go-live.
Join your peers at AI + Data Security World 2027
Six cities, one room where security, data and privacy leaders compare notes on exactly these problems: Melbourne, May 5 · San Francisco, July 15 · London, September 15 · Singapore, September 30 · Sydney, October 14 · New York, November 11.
Not ready to register? Sign up for updates and we will send agenda releases and practitioner insights as they publish.