Agentic AI Security Terminology: A 2026 Glossary

The vocabulary of agentic AI security is being written faster than any comparable stretch in software history. New terms appear every week; half of them mean different things to different vendors, and the field is moving faster than the definitions can settle. This is a working glossary: roughly eighty terms that actually matter, grouped by what they describe, each defined with a point of view rather than a neutral paraphrase.

Two things make this vocabulary worth getting right. First, agentic systems decide what to do at runtime, from natural language they were never type-checked against, so most of the old application-security vocabulary does not map cleanly onto them. Second, whoever defines the terms shapes how the whole category reasons about the problem. So these definitions take a side. The through-line you will notice across all eight sections: agentic systems change at runtime, which means security built for a fixed artifact keeps failing in the same predictable ways.

Jump to a section: The Discipline · The Architecture · The Attack Surface · The Defenses · The Metrics · The Failure Modes · The Frameworks · The Operating Posture

The Discipline

Agentic AI Security. Securing systems where AI agents take action, not just generate text. The scope is the agent’s code, the tools it can call, the memory it carries between sessions, and the permissions it runs with. Traditional application security asks whether your code is safe to run. Agentic AI security asks whether your agent is safe to let act, because the agent chooses what to do at runtime. The unit of risk moved from the function to the decision.

AI Security Engineer. An AI system that does the job a human security engineer does, continuously: reconstruct the architecture from the real code, inventory every agent, tool, and permission, trace how an attacker would chain them, decide what actually matters, fix it, and confirm the fix held. The term names a role, not a scanner. A scanner returns findings; an engineer returns judgment, and the difference is whether anything gets closed. The category exists because the work became too continuous and too voluminous for the people who used to do it, and because most teams were never able to hire that person in the first place.

Security for AI (and AI for Security). Two different problems that share a vocabulary and get confused constantly. AI for Security uses AI to do conventional security work better: faster triage, sharper detection, automated response. Security for AI protects the AI systems themselves, the agents, models, and autonomous workflows your team ships. Everything in this glossary is Security for AI. The distinction matters because the two answers sound alike and neither solves the other, so a conversation that never separates them tends to end with everyone agreeing and nothing being secured.

LLM Security. Securing the language model itself: its inputs, outputs, training data, and the ways it can be manipulated. LLM security is a subset of agentic AI security, not a synonym. A hardened model wired to unscoped tools and standing credentials is still an unsafe agent. The model is one component; the agent is the system.

AI Security Posture Management (AI-SPM). Continuous discovery and governance of every AI component in your environment, models, agents, the tools they call, the data they reach, and the security state of each. Posture management for agents is harder than for cloud resources for one reason: the inventory changes every time someone writes a prompt. When the scope is narrowed to autonomous agents and the links between them, you will also see it described as agentic posture management.

AI Bill of Materials (AI-BOM). A complete inventory of what went into an AI system: models, datasets, dependencies, and the agents and tools wired into it. The AI-BOM is the precondition for every other control on this list. You cannot secure, or even reason about, components you have never enumerated, and agentic stacks accumulate uninventoried components quickly.

AI Supply Chain Security. Securing everything your agent depends on that you did not write: foundation models, fine-tunes, datasets, skills, packages, and third-party agents. The agentic supply chain is unusual because so much of it is natural-language instruction rather than reviewable code, which means the trust decision often comes down to intent you cannot read from the bytes.

AI Red Teaming. Adversarial testing that probes an AI system for ways to make it misbehave: jailbreaks, prompt injection, data leakage, unsafe tool use. For agents, red teaming has to cover actions and not just outputs, because the dangerous failure is not a bad sentence; it is a real action taken on your systems.

AI Governance. The policies, ownership, and approval processes that decide which agents are allowed, what they may access, and who signs off. Governance is where security meets the org chart. Most agentic incidents trace back not to a clever exploit but to an agent nobody owned, running with access nobody approved.

The Architecture

AI Agent. Software that uses a model to pursue a goal by taking actions through tools, with some autonomy over the sequence. The security-relevant part of that definition is “takes actions.” An agent is not a chatbot with extra steps; it is a process with credentials and a non-deterministic plan.

Tool (Tool Use). A capability an agent can invoke: read a file, query a database, call an API, run a command. Every tool you grant is a permission you grant. The agent decides when to use it from natural language, so a tool is only as safe as the worst instruction the agent might follow while holding it.

Model Context Protocol (MCP). An open standard for connecting agents to tools and data sources through a uniform interface. MCP solved a real integration problem and created a real security one: a standard, easy way to give an agent new capabilities is also a standard, easy way to give an attacker a new path.

MCP Security. Securing the connections that let agents call external tools over the Model Context Protocol. The protocol’s flexibility is exactly what makes it risky: an agent told to use a tool will use it, so an unvalidated, over-permissioned, or impersonated tool server becomes a direct route to data exfiltration or unauthorized action.

Multi-Agent System. An application where several specialized agents collaborate to complete work. Each agent is an attack surface, and each handoff between agents is a trust boundary. The risk compounds rather than adds: an injection that lands in one agent rides its output into every downstream agent that treats that output as trusted input.

Agent-to-Agent (A2A) Communication. Agents discovering, delegating to, and coordinating with other agents. A2A turns a single agent’s blast radius into a network’s. The question that decides safety is whether one agent’s claims and outputs are verified by the next, or simply believed.

Subagent. An agent spawned by another agent to handle a piece of a task. Subagents inherit context and often permissions from their parent, which means a prompt injection in a parent can be laundered into a subagent that runs with the same access and less scrutiny.

Agent Memory (Persistent Memory). State an agent carries across turns or sessions: past instructions, retrieved facts, summaries. Memory is what makes agents useful and what makes them durable attack surface, because something planted in memory once can steer behavior long after the original prompt is gone.

Trust Boundary. Any point where data or control crosses from less-trusted to more-trusted: user input into the agent, one agent’s output into another, a tool’s response back into the model. In agentic systems the boundaries multiply and blur, because the same natural-language channel carries both data and commands.

Orchestration. The layer that routes work between models, agents, and tools and decides what runs next. Orchestration is where authority concentrates, so it is where a single compromised instruction does the most damage. Securing the orchestrator matters more than securing any one agent it drives.

Agentic Workloads. The AI systems an organization actually runs, in the two shapes they usually take. Agentic applications are the ones you build: the product itself reasons, calls tools, and acts. Agentic deployment is the one you use: agents inside your build and release pipeline reviewing pull requests and shipping code, even when the software you ship is entirely conventional. Most teams secure the first and never think about the second, which is backwards, because the agent in the pipeline usually holds more privilege than the product does.

Scan, Judge, Mitigate, Evaluate. The loop a security system runs over an agentic application: scan the code, agents, and data flows for issues; judge which ones actually matter for this application; mitigate the real ones; evaluate whether posture genuinely improved. It is described as a loop rather than a checklist on purpose. An agent that keeps building keeps reintroducing risk, so the security has to keep running. Each pass should leave your application more secure than the last.

The Attack Surface

Prompt Injection. Instructions smuggled into content an agent reads, hijacking its behavior. It is the defining vulnerability of the category for a structural reason: when natural language is both the data and the control channel, there is no deterministic way to separate “content to process” from “command to obey.”

Indirect Prompt Injection. Prompt injection delivered through content the agent retrieves rather than what the user typed: a web page, a document, an email, a tool response. It is more dangerous than the direct kind because the malicious instruction enters through a source the user never saw and the agent treats as data.

Jailbreak. Input crafted to make a model ignore its safety instructions or guardrails. Jailbreaks matter more for agents than for chatbots, because a jailbroken agent does not just say something it should not, it does something it should not, with whatever tools it holds.

Tool Poisoning. A tool, or the description an agent reads to decide how to use it, is crafted so that invoking it does harm even though the agent followed instructions correctly. The attack lives in the tool definition, which the agent treats as trusted, so the agent becomes the delivery mechanism. Anything that only inspects the agent’s own code misses it.

Excessive Agency. An agent granted more capability, autonomy, or permission than its task requires. Excessive agency is the difference between a contained mistake and an incident. The fix is boring and effective: scope each of your agents to exactly what it needs, and no more.

Confused Deputy. An agent with legitimate access tricked into using that access on an attacker’s behalf. The agent is not compromised; it is misused. Its credentials are real, its action is authorized, and the request came from the wrong place. Authentication passed; authorization never asked the right question.

Memory Poisoning. Planting malicious content in an agent’s persistent memory so it influences future behavior. Because memory survives the session, this turns a one-time injection into a standing instruction. The agent keeps following an order whose origin nobody can see anymore.

Data Exfiltration. An agent moving sensitive data to where an attacker can read it, often through a channel the agent legitimately uses. The hard part is detection: when an agent is supposed to call external services, one more outbound call to a slightly wrong endpoint does not look like an alarm.

Shadow Agents. Unmanaged AI agents running inside an organization without security oversight, the agentic version of shadow IT. They are more dangerous than an unsanctioned SaaS app because an agent does not just hold data, it acts, often with a real user’s full credentials. As agent frameworks get easier to use, the cost of spinning up an ungoverned one keeps falling.

Shadow MCP. Unauthorized or forgotten Model Context Protocol servers connected to agents without the security team’s knowledge. Each one is an ungoverned path between an agent and a backend system, invisible until someone audits what the agent can actually reach rather than what it is supposed to reach.

Supply-Chain Agent Attacks. Compromise that arrives through an installed skill, package, or third-party agent rather than through your own code. One malicious or vulnerable dependency inherits the full privileges of the agent that installed it. On open skill registries, where most packages ship a few kilobytes of natural-language instruction and no reviewable code, this is the dominant risk rather than an edge case.

Phantom Implementation. A package or skill whose professional documentation describes functionality that does not actually exist in the code. It is a trust-accumulation play: publish something attractive and inert, wait for installs, then deliver the payload in an update. The first version passes every review because there is nothing to review.

Slopsquatting. Registering a package under a name an AI commonly hallucinates, so that when an agent invents a dependency that does not exist, the name now resolves to attacker-controlled code. It is typosquatting aimed at the model’s predictable mistakes rather than the human’s.

The Lethal Trifecta. Simon Willison’s name for the combination of three capabilities in one agent: access to private data, exposure to untrusted content, and the ability to communicate externally. Each is fine alone. Together they let a single injection read your secrets and ship them out, with the agent as the courier.

Attack Chain. The specific sequence of steps that carries an attacker from untrusted input to real damage: a poisoned search result, into the agent’s context, into a tool call, into data leaving your network. The individual finding is the wrong unit of analysis for an agentic system, because no single step in that sequence is a vulnerability. The chain is the vulnerability. It also changes what a fix is worth, since one upstream control, like sanitizing tool output before it ever reaches the model, can close most of the chains at once. You do not fix everything. You break the paths.

Blast Radius. Everything a compromised agent can reach: the tools it holds, the data those tools touch, the systems downstream of them, and the other agents that treat its output as trusted. Blast radius is decided at design time by the permissions you granted, not at incident time by how clever the attacker turned out to be. It is the number most worth knowing before anything goes wrong, and the one almost nobody has actually computed.

Pipeline Agent. A coding agent operating inside your build and release pipeline: reviewing pull requests, writing fixes, running as a CI job on every push. It is the most privileged agent most organizations run and the least watched. It reads your source, holds deploy keys and cloud credentials, opens and merges pull requests, and reaches the network, while acting on untrusted input from every issue title, commit message, and dependency README that lands in its context. You do not have to be building an AI product to carry this exposure. You only have to be using agents to ship.

The Defenses

Guardrails. Controls that constrain what a model or agent can take in or put out: filters, validators, policy checks on inputs, outputs, and tool calls. Guardrails reduce the prompt-injection surface. They do not close it, because the same ambiguity that makes natural language useful is the ambiguity an attacker exploits.

Runtime Guardrails. Guardrails enforced while the agent runs, on live inputs, outputs, and actions, rather than only at design time. They matter because the dangerous moment for an agent is the action it is about to take, and only a runtime control is standing there when it happens.

Sandboxing. Running an agent or its tools in an isolated environment so that a compromise cannot reach the host, the network, or other systems. Sandboxing does not make an agent trustworthy; it makes an untrustworthy agent survivable. Assume the agent will be tricked and contain what happens next.

Least-Privilege Tool Scoping. Granting each agent only the tools and permissions its task requires, scoped as narrowly as possible. It is the single highest-impact control for agents, because most agentic damage is not exotic; it is an over-permissioned agent doing exactly what it was allowed to do.

Human-in-the-Loop (HITL). Requiring human approval before an agent takes a high-stakes action. HITL is a real control and a real bottleneck. Used on everything it becomes the thing people click through; reserved for the actions that genuinely warrant a human, it is one of the few defenses an injection cannot talk its way around.

Allowlisting. Permitting only known-good tools, endpoints, skills, or publishers, and denying everything else by default. Allowlisting trades convenience for control. In an ecosystem where any package can ship malicious natural language, default-deny is the posture that scales, and default-allow is the one that eventually pages you.

Continuous Threat Modeling. Threat modeling that re-runs as the application changes, instead of once before launch. It assumes the architecture will keep moving and keeps checking, so the model reflects what is shipping now rather than what was designed months ago.

Behavioral Analysis. Evaluating what an agent or skill would actually do when it runs, reading intent, architecture, and trust boundaries, rather than matching its bytes against known-bad signatures. For agentic packages, where the payload is often plain language and the code may not exist yet, behavioral analysis catches what signature scanning structurally cannot.

Static and Dynamic Analysis (SAST, DAST, SCA). The conventional application-security toolkit: static analysis reads source for insecure patterns, dynamic analysis probes the running application from outside, and software composition analysis checks your dependencies against known vulnerabilities. Each does its narrow job well, and none of them is obsolete. They simply do not answer the agentic question, because the risk in an agent is not a vulnerable line of code. It is an autonomous decision made from whatever landed in the context, and there is nothing there to grep for.

Semantic Logging. Recording not just what an agent did but why: the reasoning, the instruction it believed it was following, the context it acted on. Traditional logs tell you an action happened. For agents you need the why, because reconstructing an incident means reconstructing what the agent thought was being asked.

The Metrics

Mean Time to Detect (MTTD). The average time between an issue being introduced and someone noticing it. For agentic code that ships continuously, MTTD is the clock that matters most, because everything downstream, exposure, exploitation, cost, scales with how long the issue sat unseen.

Mean Time to Remediate (MTTR). The average time from detecting an issue to fully resolving it. MTTR is where agentic security either compounds or collapses: if findings detect in minutes but remediate in weeks, the detection speed bought you nothing but a longer list.

Mean Time to Mitigation (MTTM). The average time from detecting an issue to having a mitigation in place that stops the exposure, even before a full root-cause fix. MTTM is the honest operational number for “how fast did we actually reduce risk,” as distinct from how fast we noticed.

Agent Coverage. The proportion of an organization’s deployed agents that are under active security assessment rather than running unseen. The gap between agents deployed and agents covered is where shadow agents live. In security-operations contexts you will also see the same phrase describe the share of alerts an agent can handle without a human, a different measurement worth not confusing.

Drift Detection Rate. How reliably a system catches when an agent’s behavior, permissions, or posture diverge from its established baseline. Drift is the agentic norm, not the exception, because the application rewrites itself, so a low drift-detection rate means you are secured against a version of the system that no longer exists.

Critical Finding Density. The number of critical-severity findings concentrated in a single package, agent, or skill. Density is diagnostic: a legitimate tool with a few scattered weaknesses looks nothing like a deliberately malicious one, where critical findings cluster tightly around credential access and exfiltration.

Exploitability (Reachability). Whether a finding can actually be reached and triggered in your specific application, as opposed to being true in the abstract. Exploitability is the filter that turns a scanner’s output into a work list. A critical rating on a code path nothing can reach matters less than a medium on a path that untrusted input can drive, and a tool that cannot tell the two apart will keep handing you the wrong one first.

Signal-to-Noise Ratio. The proportion of a tool’s findings that represent real, actionable risk versus false positives. It is the metric scanner-heavy programs quietly fail. Past a certain noise level humans stop reading the alerts, and an unread alert is worth exactly nothing.

The Failure Modes

Open-Loop Security. A posture where detection happens, but remediation does not close automatically. Issues are found, surfaced, and then wait for a human to act. The loop is open: nothing connects “we found it” to “it is fixed.” On a system changing at agent speed, an open loop guarantees the backlog grows faster than anyone clears it.

Scanner Sprawl. Stacking up more and more scanners and treating the growing pile of findings as progress. Each scanner adds alerts; none adds judgment. More detection without prioritization or remediation does not raise your security; it raises the noise floor, and the noise floor is where real findings hide.

Alert-Only Security. Tooling that stops at telling you. An alert nobody has the context or capacity to act on is not a control. It is a timestamped record that you were warned, useful mainly to whoever writes the postmortem.

Snapshot Threat Modeling. Threat modeling done once, at design time, and treated as durable. Also called point-in-time threat modeling. For a system that rewrites itself every sprint, a snapshot is stale the moment the next feature ships. It documents the architecture you had, not the one in production now.

Static Guardrails. Guardrails written once and never revisited while the application keeps changing around them. A rule that fits the agent’s capabilities at launch quietly stops covering the capabilities it has three months later. Guardrails that do not evolve become decoration.

Dashboard Security. Measuring security by how much a dashboard can display rather than how much risk actually gets closed. A dashboard full of findings is a richer description of the problem, not evidence of a solution. Coverage of the display is not coverage of the risk.

Human-in-the-Loop Bottleneck. Putting a human approval gate on so many agent actions that people either become the constraint on shipping or start approving without reading. Overused, HITL converts into rubber-stamping, which is worse than no gate because it looks like a control while being none.

Prompt Debt. The accumulation of brittle, patched, and contradictory prompt instructions layered up over time to make an agent behave. Like technical debt, it compounds quietly and raises the odds that some edge case makes the agent do the wrong thing, and unlike code, nobody is reviewing it.

Security Toil. The manual, repetitive, judgment-light work that consumes a security team: re-triaging the same false positives, chasing down owners, copying findings between systems, re-reviewing an architecture that changed again last week. Toil scales with how much code gets produced, and agents produce code faster than any tooling before them. It is how a competent team falls behind without anyone making a single bad decision.

The Security Engineer Gap. The structural shortfall between how much code an organization ships and how many people it has who can judge whether that code is safe. The ratio was already lopsided, roughly eighty developers to one security engineer at many companies, and agentic development widened it overnight by raising output without raising headcount. Every failure mode above gets worse under this ratio, because each one is ultimately resolved by a person who does not exist.

Security Debt. The backlog of known issues you leave unresolved past the point they should have been fixed. Agentic development inflates it faster than any prior style of software, because agents generate more code, and more findings, than human review pace was ever sized for. Left unmanaged, the long tail of unfixed issues is the liability that eventually comes due.

The Frameworks

OWASP Top 10 for LLM Applications. The community-standard catalog of the most critical LLM-application risks, prompt injection, insecure output handling, excessive agency, and more. It is the common vocabulary most teams start from, and a sound baseline as long as you remember it describes the LLM layer, while your exposure spans the whole agent.

OWASP Agentic Security Initiative. OWASP’s effort to extend its risk taxonomy specifically to autonomous, tool-using agents, where the threats reach beyond what the original LLM Top 10 was scoped to cover. It reflects the field’s recognition that agentic risk is its own category, not a footnote to LLM risk.

STRIDE. A threat-modeling taxonomy that sorts threats into six kinds: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. STRIDE predates agents by decades and still works, because the six categories describe what an attacker wants rather than how the software is built. What it does not do on its own is tell you that the elevation of privilege arrived as a sentence in a web page the agent read.

MITRE ATLAS. A knowledge base of real-world adversary tactics and techniques against AI systems, modeled on the ATT&CK framework. ATLAS is how you map an abstract worry to a concrete, observed attack pattern, which is what turns a threat model from a brainstorm into something testable.

NIST AI RMF. The US National Institute of Standards and Technology’s AI Risk Management Framework, a voluntary structure for governing, mapping, measuring, and managing AI risk. It is governance-level rather than technical, useful for the program around your agents and not a substitute for controls on the agents themselves.

EU AI Act. The European Union’s risk-tiered regulation of AI systems, with obligations that scale by risk category. For security teams it is the reason “we should secure our agents” becomes “we are required to,” and the reason an unlicensed, uninventoried agent fleet is now a compliance exposure as well as a security one.

Compliance Mapping. Connecting the controls and tools you actually run to the frameworks you are held to, SOC 2, ISO 27001, NIST, and naming what is missing. Compliance mapping is where security work becomes legible to auditors, buyers, and boards. It belongs in an agentic glossary because agentic systems break the mapping quietly: the controls you documented were written for an application that has since rewritten itself, so the evidence still passes the audit while describing a system that no longer exists.

AI Security Maturity Model. A maturity model for AI security, in the tradition of the capability maturity models that came before it: a way to place a program on a path from ad-hoc and reactive through to continuous and predictive, and to see which stage it is actually at rather than which one it claims. Maturity models are easy to dismiss as scoring exercises. Their real use is arbitration, giving two people who disagree about how secure something is a shared axis to argue on.

ISO/IEC 42001. The international management-system standard for AI, the AI counterpart to frameworks like ISO 27001 for information security. It certifies that you run a managed process around AI, which is increasingly what enterprise buyers and auditors ask you to prove before they trust your agents.

The Operating Posture

Agent-Speed Security. Security that operates at the velocity agents create and change code, rather than at human-review pace. When an agent ships a feature in minutes, a security process measured in days is not slow; it is absent for the entire window that matters. Security that runs as fast as the thing it secures.

Continuous Security. Security treated as an ongoing process that runs with every change, not a gate cleared once before launch. Agentic development makes the point unavoidable: there is no “before launch” anymore when the application is rewritten daily, so a quarterly review secures a system that no longer exists.

Shift-Left for Agents. Moving security earlier, into the moment an agent’s plan or feature is being written rather than after it ships. For agents, the leftmost point is the prompt and the plan, so reviewing intent before the agent acts catches the issue while it is still cheap to fix.

Closed-Loop Security. A posture where detection connects to remediation and verification: find, fix, confirm, then run it again. The closed loop is the answer to open-loop security. Each pass carries findings all the way to resolution and verifies the fix held, so the system gets more secure over time instead of accumulating a backlog of warnings.

Defense in Depth. Layering independent controls so that no single failure is fatal: scoped permissions, sandboxing, runtime guardrails, monitoring, and human gates on the highest-stakes actions. For agents, where any one control will eventually be talked past, depth is not optional polish, it is the design.

Agent Observability. The ability to see what your agents are doing in production: their actions, tool calls, data access, and decisions, in enough detail to spot when one steps outside expected behavior. You cannot secure what you cannot see, and an agent acting with real credentials is exactly the thing you most need to watch.

Secure-by-Design for Agents. Building security into an agent’s architecture from the first design conversation, scoped tools, isolated execution, verified inputs, rather than bolting it on before launch. The architecture decides what is even possible to exploit; the controls only decide how hard. Get the architecture wrong and no amount of late hardening fully recovers.

The terms here are not settled, and the list is not finished. It reflects where the vocabulary stands in 2026, and it will change as the field does. If you take one lesson out of it, take the one the failure modes keep pointing at. Detection is not your hard problem anymore. Closing the loop is. Whatever you use to secure an agentic system has to run continuously, prioritize what is actually real, and carry findings all the way to fixed, because the system you are protecting never stops changing.