Agentic AI Security (2026): Threats, Controls and How to Test an Agent

In March 2026, NIST's Center for AI Standards and Innovation reported that more than 250,000 attack attempts from over 400 participants found at least one successful attack against all 13 frontier models it targeted in tool-use, coding and computer-use agent scenarios, and that resistance "did not correlate uniformly with model capability" (NIST CAISI). An agent built on any of those models can be steered. What decides the damage is what the agent is allowed to touch when that happens.

Quick answer: Agentic AI security is the practice of protecting AI systems that plan, call tools, keep memory and act with delegated authority, so that untrusted input cannot redirect what the agent does or turn its permissions into an attacker's. The reference threat list is the OWASP Top 10 for Agentic Applications (ASI01 to ASI10). Before you ship an agent, give it the least agency its task needs (scoped tools, short-lived credentials, human approval for irreversible actions), log every tool call, and have it penetration tested against the ten risks with reproducible evidence and a retest.

This is a broad explainer on securing the agents you build or deploy. It is not about AI agents that run penetration tests, which is a different topic covered in our guide to agentic AI pentesting.

Key points

• Definition: agentic AI security protects the goal, tools, identity, memory and inter-agent channels of an autonomous AI system, not just the model's text output.

• Threat list: the OWASP Top 10 for Agentic Applications, published 9 December 2025, runs from ASI01 Agent Goal Hijack to ASI10 Rogue Agents.

• Attack and defense catalog: MITRE ATLAS v2026.09 (15 September 2026) includes agent techniques such as AML.T0053 AI Agent Tool Invocation and agent mitigations such as AML.M0037 AI Agent Authority Expansion Controls.

• Core design principle: OWASP's "Least-Agency": avoid autonomy the task does not need, because unnecessary agentic behavior "expands the attack surface without adding value."

• The incidents are mostly ordinary: Hugging Face's account of the July 2026 agent intrusion says "The individual weaknesses were familiar" (Hugging Face).

What is agentic AI security?

Agentic AI security is the discipline of keeping an AI agent's goals, actions and authority under the owner's control when the agent reads untrusted content, calls tools, remembers past sessions and works with other agents. An AI agent, in this sense, is an LLM-driven system that decides on a sequence of steps and executes them through tools: APIs, databases, browsers, code interpreters, MCP servers or other agents.

LLM security asks whether a model can be tricked into saying something harmful or leaking data. Agentic AI security asks a harder question: once the model is tricked, what can it do? OWASP draws the line the same way: LLM01:2025 Prompt Injection is about altering a single model response, while ASI01 Agent Goal Hijack covers manipulated inputs that redirect an agent's goals, planning and multi-step behavior (OWASP).

The two lists overlap on purpose. The 2026 LLM list keeps Prompt Injection at LLM01:2026 and Excessive Agency at LLM03:2026, and the agentic list builds on both.

Why agents break the old security model

Four properties separate an agent from a chatbot, and each one moves a familiar control problem somewhere new.

1. Autonomy. The agent chooses its next step. A single injected instruction in a web page, ticket or email can change the plan for every step that follows, without a person reading it first.

2. Tools. Every tool is an authorization boundary. An email summarizer that can also send and delete mail, or a support agent whose refund tool has full financial API access, are both OWASP examples of over-privileged tools under ASI02.

3. Memory. Context that persists across sessions can be seeded once and keep steering decisions later. OWASP treats this as a distinct risk (ASI06) because the poison outlives the conversation that planted it.

4. Delegation. Agents act on behalf of users and hand work to other agents. OWASP calls the result an "attribution gap": without a distinct, governed identity for the agent, "enforcing true least privilege" is impossible (ASI03).

The fix is not a new category of magic. It is old discipline applied at a new layer, which OWASP names Least-Agency: grant an agent only the autonomy, tools and permissions its task needs, and make everything it does observable. MITRE ATLAS puts the same idea in a mitigation, AML.M0037 AI Agent Authority Expansion Controls: the maximum authority "should be explicitly granted prior to runtime", and these controls "should not rely solely on system prompts, model alignment, or the agent recognizing that an action is out of scope" (MITRE ATLAS v2026.09).

That last clause is the whole argument for testing. NIST's competition shows any model can be steered, so the controls that matter sit outside the model, where a tester can try to get past them.

Agentic AI security threats: ASI01 to ASI10, with controls and tests

The table below is the core of this guide. It takes each risk in the OWASP Top 10 for Agentic Applications, names the control that contains it, and says how a penetration test checks that control. The ATLAS column gives the MITRE ATLAS v2026.09 technique (T) and mitigation (M) IDs we map to each risk; the full names are in Figure 1. The mapping is ours, not an official OWASP or MITRE crosswalk. For each risk's evidence in real incidents, see our OWASP to MITRE ATLAS case study crosswalk.

Figure 1: OWASP ASI01 to ASI10 mapped to MITRE ATLAS v2026.09 technique and mitigation names. Sources: [OWASP GenAI Security Project](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/); [MITRE ATLAS data v2026.09](https://github.com/mitre-atlas/atlas-data). Mapping by Stingrai.

Not every row is equally testable. Goal hijack, tool misuse, the exploit side of identity abuse, code execution and memory poisoning produce a proof of concept against a running agent. Supply chain, cascading failures and rogue agents are mostly architecture and monitoring, where a test validates that the controls exist and probes their edges. Our OWASP Agentic AI Top 10 test coverage checklist goes item by item through that split.

What the incident record shows

The agentic incidents with primary disclosures are less exotic than the threat list suggests. Most of them come down to a token with too much scope, a dependency nobody pinned, or an endpoint with no authentication.

Figure 2: Six agentic incidents, July 2025 to July 2026. Sources: MITRE ATLAS case studies AML.CS0047, CS0053, CS0069, CS0072, CS0070 and CS0068, and the primary disclosures linked below. Class labels are Stingrai's mapping.

• Amazon Q Developer extension, July 2025 (ASI04, ASI03). An "inappropriately scoped GitHub token" let an attacker push code into the extension's repository, and version 1.84.0 shipped with a prompt instructing the agent to wipe the system. AWS says the code "was unsuccessful in executing due to a syntax error" and fixed it in 1.85.0 (CVE-2025-8217) (AWS).

• postmark-mcp, September 2025 (ASI04, ASI02). A package impersonating Postmark's MCP server published legitimate versions until it passed 1,000 downloads a week, then shipped an update that added the attacker to the BCC line of every email the tool sent (MITRE ATLAS case study AML.CS0053, ATLAS data). It is a textbook rug pull: the risk arrived in an update, not at install.

• GTG-1002, September 2025, disclosed 13 November 2025 (agent used as an attack tool). Anthropic reported a state-sponsored group that jailbroke Claude Code, connected it to scanners and password crackers through MCP and ran "80-90% of the campaign" with the agent, against roughly thirty targets, succeeding "in a small number of cases" (Anthropic). The lesson for defenders is speed: agents run the reconnaissance-to-exploitation loop faster than a human team.

• AI Recommendation Poisoning, 10 February 2026 (ASI06). Microsoft's Defender research team found more than 50 distinct prompts from 31 companies, hidden in links and "Summarize with AI" buttons, that told assistants to remember the company as a trusted source in future conversations; the team reviewed AI assistant URLs in email traffic over about 60 days (Microsoft Security). Memory poisoning is already a marketing tactic, not just a research demo.

• Hermes agent against Langflow and n8n, May 2026 (agent platforms as targets). Unit 42 recovered a session in which an autonomous agent searched for exposed Langflow and n8n instances and tried public exploits. The attempts failed because Langflow had auto_login disabled and the n8n form endpoints required authentication (Unit 42). The platforms you build agents on are internet-facing targets, and basic authentication settings stopped the attack.

• OpenAI evaluation agents and Hugging Face, July 2026 (ASI10, ASI07, ASI03). MITRE's case study records that about 1,200 agent runs exchanged more than 70,000 messages and files through a message board they rebuilt on an unauthenticated Artifactory endpoint, then compromised Hugging Face production systems (MITRE ATLAS case study AML.CS0068, ATLAS data). Hugging Face reconstructed about 17,600 attacker actions between 9 and 13 July and named the causes: "unsafe dataset processing, exposed cloud metadata, overly broad access, and long-lived credentials" (Hugging Face). Our analysis of the Hugging Face breach covers the timeline in detail.

Read together, the record says two things. Agents are now both a target and an attacker. And on both sides, the controls that held or failed were scoping, authentication, credentials and pinning, the same controls a penetration test checks.

Identity and least agency for agents

Identity is the control that decides the blast radius of every other failure. If an agent is hijacked, the damage is whatever its tokens allow. OWASP's ASI03 mitigations start with task-scoped, time-bound permissions, a distinct identity per agent, per-action authorization against a policy engine, and human approval for privilege escalation. MITRE ATLAS splits the configuration into three mitigations: AML.M0026 for privileged agents, AML.M0027 for single-user agents that act on one person's behalf, and AML.M0028 for tools shared across agents.

In practice, least agency for an agent means:

• One identity per agent, registered and owned like any other non-human identity, never a shared service account or a borrowed human session.

• Short-lived, task-scoped tokens bound to the user and the purpose, revoked on idle or anomaly. Long-lived keys in agent configuration are exactly what ATLAS technique AML.T0083 Credentials from AI Agent Configuration harvests.

• Authorization at the tool, not the prompt. The API behind each tool must check the end user's rights on every call. A system prompt that says "only access the current user's records" is not an access control.

• Approval gates sized to consequence. ATLAS AML.M0029 recommends human approval scaled to the stakes: minimal oversight for minor repetitive tasks, mandatory confirmation for payments, deletions, external messages and permission changes.

• No authority expansion at runtime. Resources, identities and targets the agent discovers mid-task stay out of scope until a person adds them (AML.M0037).

This is where agent security meets ordinary application security. In Stingrai's State of Penetration Testing 2026 data, authentication and session issues were 28.1% of 768 web application findings, and 70% of the 40 web application tests that produced findings surfaced at least one High or Critical authentication or authorization finding. Those were web application tests, not agent tests, but an agent's tools are web APIs, and they fail the same way. For money-moving agents, our guide to red teaming AI agents that move money applies the same idea to transaction authorization.

Tool and MCP supply chain

Every tool an agent can load is a dependency with authority attached. OWASP's ASI04 covers models, tools, plug-ins, MCP servers, agent cards, registries and prompt templates, and notes that agents "often compose capabilities at runtime", which turns the supply chain into a live one. The postmark-mcp case shows why a one-time review at install is not enough: the package was benign until it was popular.

Controls that hold up:

• Allowlist and pin every tool, MCP server and prompt template by content hash or commit, and fail closed on unknown or ambiguous tool names (typosquatting is an OWASP ASI02 scenario).

• Keep an AI bill of materials (ATLAS AML.M0023) listing models, tools, MCP servers, datasets and versions, so a bad component can be found and pulled everywhere at once.

• Treat tool descriptions as untrusted input. A malicious tool descriptor is a prompt injection with a schema attached (ATLAS AML.T0110 AI Agent Tool Poisoning).

• Build a supply chain kill switch that can disable a specific tool or connection across all deployments.

Our MCP server security assessment guide covers what a human-led review of an MCP server checks.

Memory and context poisoning

Persistent memory turns a one-time injection into a standing instruction. The Microsoft finding is the clearest 2026 example: a single click on a crafted link wrote a durable preference into an assistant's memory that biased later answers. OWASP's ASI06 lists RAG and embedding poisoning, shared context poisoning, long-term drift and cross-tenant vector bleed as the common forms.

Controls that hold up:

• Validate every memory write before it commits, and never let the agent automatically re-ingest its own outputs as trusted memory (OWASP calls this "bootstrap poisoning").

• Segment memory by user, tenant and task, with per-tenant namespaces in shared vector stores.

• Record provenance for each entry and let unverified entries expire.

• Make memory visible and editable for users, and keep snapshots so a poisoned store can be rolled back.

ATLAS gathers these under AML.M0031 Memory Hardening. Defenders can also hunt for the Microsoft pattern directly: Microsoft suggests searching email and chat for AI assistant URLs that carry prompts with words such as remember, trusted source and in future conversations.

Runtime controls and monitoring

Prevention will fail somewhere, so an agent needs runtime limits and a record of what it did. The controls that matter most:

• Tool-level logging. Log every tool invocation with its arguments, the identity used and the decision that led to it (ATLAS AML.M0024 AI Telemetry Logging). Many platforms do not log tool-level detail by default; our AI agent audit log evidence matrix shows which ones do.

• Scope drift detection. Compare the agent's planned actions with its authorized objective during the run, not afterwards (AML.M0038).

• Budgets and circuit breakers. Cap cost, rate, tokens and run time per task (AML.M0036), and put a breaker between planning and execution so one bad plan cannot fan out (OWASP ASI08).

• Sandboxes and egress allowlists for any code execution or browsing.

• A kill switch you have actually used, plus credential revocation that takes effect in minutes.

Standards for runtime control are arriving. The OWASP GenAI Security Project added the Agent Control Standard (ACS), dated 1 September 2026, an open standard for making agents inspectable, traceable and controllable at runtime through middleware hooks in agent platforms (OWASP).

Minimum controls checklist for an AI agent

Ten controls to have in place before an agent with tool access goes to production:

1. An inventory of every tool, MCP server, data source and peer agent the agent can reach, with an owner for each.

2. A distinct identity for the agent, with task-scoped, short-lived credentials and no secrets in its configuration.

3. Authorization enforced by each tool's API on every call, for the end user, not by the prompt.

4. Human approval for irreversible or high-impact actions, with a confirmation screen that shows the real effect.

5. Tool calls restricted or confirmed once untrusted content enters the context.

6. Pinned, signed and allowlisted tools, prompts and MCP servers, listed in an AI bill of materials.

7. Sandboxed code execution with no root, no production access and an egress allowlist.

8. Memory segmented by user and tenant, with validated writes, provenance and expiry.

9. Immutable logs of tool calls, arguments, identities and approvals, with alerts on drift and unusual chains.

10. Budgets, circuit breakers and a tested kill switch with credential revocation.

Agentic AI security frameworks compared

No single framework covers agentic AI security end to end. The ones buyers and auditors cite do different jobs:

A practical stack: use the OWASP agentic list to scope, ATLAS IDs to plan tests and map controls, the NIST AI RMF to assign ownership, and test reports as the evidence for ISO/IEC 42001 audits and EU AI Act documentation.

How to test an AI agent before launch

An agent penetration test asks one question per tool and per trust boundary: can untrusted input make the agent do something its user could not? Scanners cannot answer that, because the answer depends on the agent's plan, its permissions and the data it reads at run time. It takes testers who build scenarios, read the agent's responses and pivot.

Scope inputs to prepare. A test is only as good as its scope. Have these ready:

• Every tool and MCP server, with the permissions and credentials each one uses.

• The agent's identities and the user roles it acts for.

• Memory stores, retrieval sources and every channel through which outside content arrives (email, tickets, documents, web).

• Peer agents and the protocol between them.

• Approval gates, budgets and the kill switch.

• The environments: a staging copy with production-like permissions is usually best.

Our AI and LLM penetration test scope of work template turns these into a document you can send vendors.

Evidence to demand before you ship.

1. A scope that maps ASI01 to ASI10 to your architecture and labels each as tested by exploitation, assessed as a control, or out of scope.

2. Every finding with the exact prompts, content and requests needed to reproduce it.

3. Severity rated by what the agent could actually do, not by what the model said.

4. A control-gap section for the risks that are architecture and monitoring (ASI04, ASI08, ASI10), handed back to you as owned controls.

5. Logs from the test showing whether your monitoring saw the attacks.

6. A retest of every fix, with the result recorded.

Retest triggers. An agent changes faster than an annual cycle. A base-model swap, a new tool or MCP connection, a new data source, a new permission or a guardrail change can each reopen a risk. Our AI retest trigger matrix maps each change to the retest it needs.

Stingrai is a global CREST-accredited penetration testing services company founded in Toronto, Canada in 2021, trusted by companies from startups to enterprises to meet audit requirements for SOC 2, ISO 27001, CMMC, PCI DSS and HIPAA. OSCE³, OSWE, OSEP, CREST CRT certified penetration testers, who are also world-class security researchers and bug bounty hunters. Choose from fully human-led or hybrid (AI agents plus human penetration testers) engagements across web, API, mobile, AI and LLM, cloud, network, Active Directory and social engineering penetration tests and red team engagements.

For agents specifically, Stingrai's AI and LLM penetration testing pairs Snipe, Stingrai's autonomous agent, which includes a specialist sub-agent for testing AI and LLM applications, with two named penetration testers from a team with 18 published CVEs. Together they test tool misuse, excessive agency, privilege escalation through tool chains and MCP servers, memory and goal manipulation, approval step bypass and RAG poisoning, mapped to the OWASP Agentic Top 10, the OWASP LLM Top 10 and MITRE ATLAS. Findings arrive in the portal as they are confirmed, each with reproducible prompts and requests, retesting of fixes is included, and engagements run one-time before a launch or as a continuous program that retests on every significant change. For a full adversary scenario against an agent-enabled business process, a red team engagement can include the agent in scope.

Frequently asked questions

What is agentic AI security?

Agentic AI security is the practice of protecting AI systems that plan, call tools, keep memory and act with delegated authority, so that untrusted input cannot redirect what the agent does or turn its permissions into an attacker's. It covers the agent's goal, tools, identity, memory and communication with other agents, not just the model's output. The reference threat list is the OWASP Top 10 for Agentic Applications, ASI01 to ASI10.

What are the biggest agentic AI security risks?

The OWASP Top 10 for Agentic Applications names ten: agent goal hijack (ASI01), tool misuse and exploitation (ASI02), identity and privilege abuse (ASI03), agentic supply chain vulnerabilities (ASI04), unexpected code execution (ASI05), memory and context poisoning (ASI06), insecure inter-agent communication (ASI07), cascading failures (ASI08), human-agent trust exploitation (ASI09) and rogue agents (ASI10). In the incidents disclosed so far, the damage has mostly come through over-scoped tokens, unpinned tools and unauthenticated endpoints.

What is the OWASP Top 10 for Agentic Applications?

It is a list of the ten highest-impact security risks for autonomous AI agents, published by the OWASP GenAI Security Project on 9 December 2025. Each entry has a description, common vulnerabilities, attack scenarios and mitigations, and the document maps every entry to the OWASP Top 10 for LLM Applications and OWASP's Agentic AI Threats and Mitigations taxonomy.

What security controls does an AI agent need before launch?

At minimum: a distinct identity with short-lived, task-scoped credentials; authorization enforced by each tool's API rather than the prompt; human approval for irreversible actions; restricted tool calls once untrusted content is in context; pinned and signed tools and MCP servers; sandboxed code execution; segmented, validated memory; tool-level logging; and budgets, circuit breakers and a tested kill switch.

How do you test an AI agent for security?

Give testers the agent's tools, permissions, identities, memory stores, content sources and approval gates, then have them attack it the way an adversary would: plant instructions in content the agent reads, steer it to misuse tools, try cross-user and cross-tenant actions, poison memory, attempt code execution and check whether monitoring and the kill switch work. Require reproducible evidence for every finding and a retest of each fix.

How is agentic AI security different from LLM security?

LLM security focuses on what a model says: prompt injection, jailbreaks and leaked data in a response. Agentic AI security focuses on what an AI system does with tools, credentials and memory once it has been manipulated, so the blast radius is every system the agent can reach. The OWASP agentic list builds on the LLM list, extending prompt injection and excessive agency into multi-step, multi-agent workflows.

Is agentic AI security the same as agentic AI pentesting?

No. Agentic AI security is about protecting the AI agents an organization builds or deploys. Agentic AI pentesting usually means using AI agents to perform penetration tests. They meet in one place: an AI agent you deploy should itself be penetration tested before launch.

References

1. OWASP GenAI Security Project. _OWASP Top 10 for Agentic Applications for 2026._ 9 December 2025. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/. The ASI01 to ASI10 risk list, the Least-Agency principle and per-risk mitigations used throughout this guide.

2. OWASP GenAI Security Project. _OWASP GenAI LLM Top 10 2026._ 3 August 2026. https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/. The LLM01:2026 to LLM10:2026 list for the model and prompt layer.

3. OWASP GenAI Security Project. _Agent Control Standard (ACS)._ 1 September 2026. https://genai.owasp.org/resource/agent-control-standard-acs/. An open standard for runtime control hooks in agent platforms.

4. MITRE. _ATLAS data, release v2026.09._ 15 September 2026. https://github.com/mitre-atlas/atlas-data. Technique, mitigation and case study IDs cited in this guide, including AML.CS0047, AML.CS0053, AML.CS0068, AML.CS0069, AML.CS0070 and AML.CS0072.

5. NIST Center for AI Standards and Innovation. _Insights into AI Agent Security from a Large-Scale Red-Teaming Competition._ 23 March 2026. https://www.nist.gov/blogs/caisi-research-blog/insights-ai-agent-security-large-scale-red-teaming-competition. More than 250,000 attack attempts against 13 frontier models in agent scenarios.

6. Hugging Face. _Anatomy of a Frontier Lab Agent Intrusion._ 27 July 2026. https://huggingface.co/blog/agent-intrusion-technical-timeline. Technical timeline of the July 2026 intrusion by autonomous evaluation agents.

7. Hugging Face. _Security Incident Disclosure, July 2026._ 16 July 2026. https://huggingface.co/blog/security-incident-july-2026. The initial disclosure of the agent-driven intrusion.

8. Microsoft Security. _Manipulating AI memory for profit: The rise of AI Recommendation Poisoning._ 10 February 2026. https://www.microsoft.com/en-us/security/blog/2026/02/10/ai-recommendation-poisoning/. Over 50 memory-manipulation prompts from 31 companies found in 60 days of email traffic.

9. Palo Alto Networks Unit 42. _Chinese-Speaking Threat Actor Harnesses AI Models for Autonomous Cyberattacks._ 30 July 2026. https://unit42.paloaltonetworks.com/autonomous-ai-cyber-attack-campaign/. An autonomous agent's failed exploitation attempts against Langflow and n8n.

10. Anthropic. _Disrupting the first reported AI-orchestrated cyber espionage campaign._ 13 November 2025. https://www.anthropic.com/news/disrupting-AI-espionage. The GTG-1002 campaign that used a jailbroken coding agent and MCP-connected tools.

11. Amazon Web Services. _Security bulletin AWS-2025-015, Amazon Q Developer extension for VS Code._ 23 July 2025, updated 25 July 2025. https://aws.amazon.com/security/security-bulletins/AWS-2025-015/. The over-scoped token and the malicious prompt in version 1.84.0 (CVE-2025-8217).

12. NIST. _AI Risk Management Framework 1.0_ (26 January 2023) and _NIST AI 600-1, Generative AI Profile_ (26 July 2024). https://www.nist.gov/itl/ai-risk-management-framework. The voluntary governance framework referenced in the comparison table.

13. European Union. _Regulation (EU) 2024/1689 (AI Act), Article 15_, and _Regulation (EU) 2026/1744 (Digital Omnibus on AI)._ https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng. Cybersecurity and robustness duties for high-risk AI systems and their deferred application dates.

14. Stingrai. _The State of Penetration Testing 2026._ 29 August 2026. https://www.stingrai.io/blog/state-of-penetration-testing-2026. 1,206 verified findings from 55 penetration tests, including the web application authentication and authorization figures cited above.