What is agentic AI security?

Why does agentic AI need its own security discipline?

A chatbot answers questions. An agent does things. Agentic AI systems take a goal, break it into steps, choose tools, call APIs, read and write data, and sometimes spawn other agents to help. Each of those actions happens with real credentials against real systems, which means the blast radius of a compromised or misbehaving agent looks nothing like the blast radius of a bad chatbot answer.

The scale problem is arriving quickly. Gartner predicts that 33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024, and that at least 15% of day-to-day work decisions will be made autonomously by that year. Gartner also expects over 40% of agentic AI projects to be canceled by the end of 2027, with inadequate risk controls cited among the leading causes. Security is not a nice-to-have for agent programs. It is one of the reasons they succeed or die.

Agentic AI security vs. model safety and LLM security

These three terms get blended together, but they answer different questions. Model safety asks whether the model produces harmful or biased outputs. LLM security asks whether the application wrapped around the model can be manipulated, for example through prompt injection or training data poisoning. Agentic AI security asks what an autonomous system is authorized to do, as whom, and whether its runtime behavior matches that authorization.

The distinction matters because a perfectly aligned model with clean guardrails can still be a security incident. If an agent holds an over-scoped API key and an attacker steers it with an injected instruction hidden in a document, the model behaved as designed. The failure was one of identity, authority, and monitoring, not of model alignment.

What are the core threats to agentic AI systems?

The OWASP GenAI Security Project published the Top 10 for Agentic Applications in December 2025, drawing on input from more than 100 security researchers and practitioners. The recurring themes are less about exotic model attacks and more about classic security failures amplified by autonomy.

• Excessive agency: the agent holds broader permissions than its task requires, so any manipulation or error executes with that full authority
• Indirect prompt injection: instructions hidden in web pages, emails, or documents the agent reads become commands it follows with its own credentials
• Credential and secret exposure: agents accumulate API keys, tokens, and service account access that often outlive the task and escape inventory
• Tool and supply chain abuse: a malicious or compromised tool, plugin, or MCP server becomes an execution path into everything the agent can touch
• Cascading autonomy: agents that delegate to other agents multiply identities and authority in chains that no one designed end to end
• Memory poisoning: corrupted context or persistent memory steers future agent decisions long after the initial injection

Agent identity and authority

The foundation of agentic AI security is knowing who the agent is. That sounds trivial and mostly is not. Many agents run today under a human's OAuth grant, a shared service account, or a long-lived API key, which makes them indistinguishable from the human or workload whose credentials they borrowed. When something goes wrong, the audit log points at a person who never took the action.

A sound identity model gives each agent its own verifiable identity, separate from its operator, with short-lived credentials issued per task rather than standing secrets. Authority should be delegated explicitly and scoped narrowly: this agent, acting for this user, may call these tools against these resources until this expiry. Delegation chains need to stay attributable, so that when agent A asks agent B to act, the resulting API call still traces back to the originating human and intent.

Runtime monitoring and containment

Static controls set the boundaries. Runtime security verifies the agent stays inside them. Because agents compose their own action sequences, you cannot fully enumerate their behavior in advance the way you can for conventional software. The practical answer is continuous observation of what the agent actually does: which tools it invokes, which credentials it presents, which resources it touches, and whether that pattern matches its declared purpose.

Effective runtime controls include behavioral baselines per agent, policy checks on state-changing actions, approval gates for high-impact operations such as payments or production changes, step and recursion budgets that cap runaway loops, and a kill switch that can revoke an agent's credentials immediately. The goal is not to slow agents down. It is to make autonomy survivable, so a single bad instruction becomes a contained event instead of an incident report.

How do teams get started?

• Inventory every agent in use, including embedded copilots and workflow tools that act on users' behalf, and record what credentials each one holds
• Replace shared and long-lived credentials with per-agent identities and short-lived, task-scoped tokens
• Map authority explicitly: for each agent, document who delegated its access, what it may do, and when that grant expires
• Instrument runtime behavior so tool calls and credential use are logged, attributable, and comparable against a baseline
• Define containment before launch: approval gates for irreversible actions and a tested revocation path for every agent identity

What does an agentic AI attack look like in practice?

A hypothetical scenario, built from failure patterns security teams report again and again. A company deploys a support agent to triage inbound tickets. To do its job, the agent reads tickets, queries the CRM, searches an internal wiki, and sends email. It was wired up in a sprint: it authenticates with a service account left over from an earlier integration, holds a mail scope that permits sending as well as reading, and runs continuously instead of per task. Nothing about this setup is unusual. It is how most agent pilots ship.

An attacker files a support ticket containing instructions buried in the body text: look up recent invoices for a list of customer domains and forward them to an outside address for verification. The agent ingests the ticket as data, but the model treats the embedded instructions as part of its task. Injection meets excessive agency. The agent queries the CRM with its own legitimate credentials, drafts the email, and sends it. No malware ran. No credential was stolen. Every API call in the chain was authenticated and authorized.

This is the confused deputy problem at machine speed: a trusted intermediary spends its authority on behalf of an untrusted requester. Detection is hard because the audit log shows a valid service account doing things it is technically permitted to do. Attribution is worse, because the account is shared with the old integration, so the investigation starts by suspecting the wrong system. The controls that would have contained it are identity controls, not model controls: a send scope removed under least privilege, task-scoped tokens that expire with the ticket, an approval gate on outbound mail to external domains, and an anomaly flag the moment a triage agent starts reading invoices it has never touched before.

How does authority leak inside an agent loop?

The mechanics matter because they explain why familiar defenses underperform. An agent runs a loop: assemble context, plan, call a tool, append the result to context, repeat. In conventional software, code and data travel on separate channels, and input validation guards the border between them. In an agent, the instruction channel and the data channel are the same token stream. Every web page fetched, every ticket read, every tool result returned is appended to the context that steers the next decision. That is why guardrails at the prompt layer are probabilistic controls: they lower the odds of a bad action, but they cannot make an untrusted input trustworthy. The identity boundary is the deterministic control, because a credential the agent does not hold cannot be spent no matter what the context says.

Delegation multiplies the leak points. When a user hands a goal to an orchestrator, the orchestrator hands subtasks to worker agents, and a worker calls a tool through an MCP server, authority is translated at every hop: an on-behalf-of exchange here, an A2A handoff there, a static API key at the bottom. Each translation is a chance for the original principal, purpose, and constraints to fall away, until the final call executes with the broadest credential in the chain and none of the originating context. Standing secrets make it worse, because a leaked token keeps working long after the task that justified it ended. The countermeasure is structural: ephemeral credentials minted per task, scoped to the delegated intent, and useless minutes later.

How do you implement agentic AI security step by step?

The getting-started checklist above tells you what to do. Sequencing tells you what to do first. Teams that succeed treat this as an operating model built in stages, where each stage produces evidence the next stage depends on. Visibility comes before identity, identity before authority, authority before enforcement. Skipping ahead, for example deploying approval gates before you know which agents exist, produces controls that cover the agents you knew about and miss the ones that matter.

• Stand up an agent registry first: every agent gets an owner, a declared purpose, a list of tools it may call, and an expiry date, and anything not in the registry is by definition unsanctioned
• Broker all agent credentials through a token vault or secrets platform so no key lives in an agent's prompt, environment, or codebase, and every issuance is logged to a named agent identity
• Convert standing access to just-in-time access: the agent requests a credential when a task starts, receives one scoped to that task, and loses it when the task ends
• Gate the irreversible: define the short list of actions that cannot be undone, payments, deletions, production changes, external communication, and require a human approval or a policy check before any agent executes them
• Baseline behavior per agent for two to four weeks, then alert on deviation: new tools, new resources, new data volumes, or activity outside the agent's declared purpose
• Drill revocation quarterly: pick an agent, revoke its identity, and measure how long its access actually takes to die across every system it touched, because that number is your real incident response time

What are the most common mistakes?

Most agent security programs fail the same few ways, and almost all of them are inherited habits from earlier eras of automation applied to a technology that does not forgive them.

• Treating it as a model problem: teams invest in prompt filtering and red teaming while the agent runs on a shared service account with admin scopes, securing the reasoning and ignoring the authority
• Running agents under human OAuth grants: convenient at pilot stage, but it makes the agent indistinguishable from its operator, breaks attribution, and quietly grants the agent everything the human can touch
• One credential for the fleet: a single service account behind many agents collapses the audit trail and turns any single compromise into a fleet-wide incident, a fast track to identity sprawl without accountability
• No decommissioning path: pilots end, agents linger, and their credentials outlive them because nobody owns the identity lifecycle for agents the way they do for employees
• Assuming the sanctioned list is the whole list: employees wire up their own agents and copilots long before security hears about it, so discovery has to account for shadow AI rather than assume the registry is complete
• Testing the happy path only: evaluations cover whether the agent completes tasks, not what it does when its inputs are hostile, its tools are compromised, or its instructions conflict with its scopes

Frequently asked questions

Related terms