Agentic AI Security: The New Attack Surface and How to Defend It

By ScruteX Published 30-07-2026

Enterprises are handing real authority to AI agents: software that can read data, call APIs, move money, and act with limited human review. That autonomy is the point, and it is also the problem. An agent that can act on your behalf can be manipulated into acting against you.

Agentic AI security is the practice of protecting autonomous and semi-autonomous AI agents, and every system those agents can reach, from manipulation and abuse. It covers the model layer, the tools and APIs the agent calls, the credentials it holds, the memory it keeps, and the infrastructure it runs on. The defining difference from earlier AI security work is consequence: a manipulated chatbot says something wrong, a manipulated agent does something wrong.

This guide maps the risk, walks the vectors one at a time, separates what is externally observable from what is not, and sets out where defenses start. It also tries to be honest about what nobody knows yet, because the guidance in this area is still being written.

What is agentic AI security?

Agentic AI security is the discipline of securing AI agents, meaning systems built on large language models that plan, hold memory, call tools, and take actions rather than only generating text, along with the data, credentials, and downstream systems those agents can reach.

A traditional assistant answers a question. An agent books the flight, updates the record, sends the email, files the ticket, and calls the API. The security question shifts from "what might it say" to "what might it do, who can make it do that, and what does it have access to when they do."

Four properties separate agents from the chatbots security teams spent two years hardening:

Property	Why it changes the risk
Autonomous planning	The agent decides its own intermediate steps, so an attacker who shifts the goal gets a whole chain of actions, not one bad answer
Persistent memory	Poisoned context survives the session and shapes later decisions for other users
Tool and API access	The agent holds live credentials to systems that matter
Multi-agent coordination	Agents trust each other's output, so one compromised agent contaminates the others

Put those together and you get the single sentence that matters most in this field: with a normal application, an attacker who injects malicious input still has to find a way to execute something, but with an agent, execution is the feature. The agent is built to act on instructions. An attacker who can shape those instructions gets action for free.

Why do AI agents break the old security model?

Application security assumes a boundary between code and data. Input is data, code is code, and the job is stopping data from becoming code. SQL injection, command injection, and cross-site scripting are all versions of that same failure.

Agents remove the boundary by design. Natural language is simultaneously the data the agent reads and the instruction set it obeys. There is no parser to fix, no parameterised query to write, no escaping function that reliably separates the two. That is why prompt injection has resisted a clean fix since it was first described, and why OWASP still ranks it as the top risk for LLM applications rather than treating it as solved.

Three second-order effects follow, and they are the ones security leaders tend to miss.

Trust boundaries move to runtime. Traditional threat models assume you know at design time which components talk to each other. Agentic systems compose tools, plugins, and other agents dynamically while running. The threat model is assembled at execution, which means a static architecture review has a short shelf life.

Identity gets murky. When an agent acts, whose identity is on the action? Most deployments run agents on a service account or an inherited user token, so audit logs show a human or a generic principal rather than "the agent acting under instruction from an untrusted email." Non-human identity becomes the control plane, and most identity programmes have not caught up.

Errors compound instead of failing. A wrong answer in a chatbot is visible and contained. A wrong step in an agent chain feeds the next step, then persists to memory, then influences a second agent. Small errors amplify rather than surface.

What does OWASP's Top 10 for Agentic Applications cover?

On 10 December 2025, at Black Hat Europe and the OWASP Agentic Security Summit, the OWASP GenAI Security Project released the first Top 10 for Agentic Applications, built over roughly a year with input from more than 100 researchers, practitioners, and vendors. The published list carries a 2026 label and uses ASI identifiers, so practitioners now reference agentic risks as ASI01 through ASI10.

ID	Risk	What it means in practice
ASI01	Agent Goal Hijack	An attacker alters the agent's objective or plan through malicious content
ASI02	Tool Misuse and Exploitation	The agent uses legitimate tools in unsafe ways, including parameter tampering and tool chaining
ASI03	Identity and Privilege Abuse	The agent inherits or escalates high-privilege credentials across systems
ASI04	Agentic Supply Chain Vulnerabilities	Compromised tools, plugins, prompt templates, or external servers enter the chain
ASI05	Unexpected Code Execution	The agent writes or runs code and commands unsafely
ASI06	Memory and Context Poisoning	Attackers corrupt agent memory, embeddings, or RAG stores to steer later decisions
ASI07	Insecure Inter-Agent Communication	Spoofed identities, replayed messages, and tampering between agents
ASI08	Cascading Failures	Small errors propagate across planning, execution, and memory
ASI09	Human Agent Trust Exploitation	Users over-trust confident agent output and approve harmful actions
ASI10	Rogue Agents	A compromised or misaligned agent acts harmfully while looking legitimate

Two things about this list deserve attention beyond the names.

First, the risks combine. OWASP's own framing shows goal hijack (ASI01) leading to tool misuse (ASI02), which triggers cascading failures (ASI08), which humans fail to catch because they over-trust the agent's confident output (ASI09). Single-vector threat modelling will miss most real attack paths.

Second, the list introduces the principle of least agency: grant an agent only the autonomy needed for safe, bounded tasks. That is least privilege extended from permissions to decision-making authority, and it is the most portable idea in the document. A security team that adopts nothing else from the list can still ask, for every agent in production, "what is the smallest amount of autonomy this task needs?"

The agentic list extends rather than replaces the OWASP Top 10 for LLM Applications 2025, where prompt injection holds the LLM01 position. ASI01 is prompt injection plus excessive autonomy, amplified by multi-step execution. If your team has already mapped controls to the LLM Top 10, the agentic list is a delta, not a restart.

What does the agentic attack surface look like in practice?

Five vectors carry most of the real-world risk today. Each one is described here with what an attacker does and what defenders can observe.

Prompt injection, direct and indirect

An attacker plants instructions in content the agent reads: a web page, a PDF, a support ticket, a calendar invite, a code comment, an email. The agent processes it as part of normal work and follows the instructions.

The reference case is EchoLeak (CVE-2025-32711, CVSS 9.3), disclosed by researchers at Aim Security in June 2025. A single crafted email, with no user interaction, could cause Microsoft 365 Copilot to pull internal content into its context and exfiltrate it to an attacker-controlled destination. The researchers chained several bypasses, including evading Microsoft's cross-prompt injection classifier and abusing link handling to move data out. Microsoft patched it server-side and reported no confirmed exploitation in the wild.

What makes EchoLeak instructive is not the specific bug, which is fixed. It is the class. The payload was plain text inside a normal business document. No malware signature, no executable, no attachment to sandbox. The controls a SOC would normally reach for do not see it.

Excessive agency and privilege inheritance

An agent granted more permission than its task needs becomes a larger blast radius the moment it is manipulated. An agent that only needs to read a calendar but can also send mail is one hijack away from sending on your behalf, from a trusted internal address, to your own staff and customers.

This is where non-human identity discipline decides the outcome. Most agents authenticate with long-lived static credentials rather than short-lived scoped tokens. Research by Astrix published in October 2025, covering more than 5,200 servers in the Model Context Protocol ecosystem, reported that a majority relied on static API keys or personal access tokens, with only a small fraction using OAuth. Treat that figure as directional rather than exact, since the ecosystem changes monthly, but the direction has held across every study since.

Exposed agent endpoints and infrastructure

Agents run somewhere. Their orchestration servers, tool servers, management consoles, and inference endpoints are internet-facing assets, and they get exposed and misconfigured like any other asset.

The Model Context Protocol, now the common connector between agents and tools, has become the clearest measurable example. Trend Micro's July 2025 research identified 492 MCP servers reachable on the public internet with no client authentication and no traffic encryption, collectively exposing over 1,400 tools. Follow-up research by the same team found that count had nearly tripled to 1,467, with exposure spreading into cloud infrastructure. Separate work by Knostic identified 1,862 exposed MCP servers and reported that all 119 servers it sampled for manual verification allowed tool listings to be read without authentication, with a small minority applying any access scoping to tool permissions. Censys measurements reported in April 2026 counted more than 12,000 internet-reachable MCP services, the majority unauthenticated.

The counts differ because the scanning methods differ, and every number here is a snapshot of a fast-moving surface. The consistent finding across independent teams is what matters: a large share of agent tool infrastructure is reachable from the internet without authentication, and an unauthenticated tool listing is a capability map handed to whoever asks. The protocol was designed for local and trusted-network use, and its specification does not require authentication, so every exposure to the public internet is a deployment decision rather than a protocol failure.

Leaked credentials and keys

Agents authenticate to the tools they use. That means API keys, service tokens, database strings, and cloud credentials sitting in configuration files, environment variables, and repositories. Those secrets leak the way every secret leaks: committed to public code, captured by infostealer malware, dumped in breach corpora, traded on forums and Telegram channels.

A leaked agent key is different in kind from a leaked read-only key. It is a leaked ability to act, often against several connected systems at once, using an identity that internal logging treats as legitimate. Credential exposure monitoring was already a core external-risk control. Agent adoption raised the value of every stolen key it finds.

Tool and supply-chain abuse

Agents call tools, and those tools come from registries, marketplaces, and open-source repositories that receive far less scrutiny than a production dependency. A poisoned tool description can hijack behaviour before any user types anything, because tool descriptions flow directly into the model's context. A malicious package can execute hidden functionality under the agent's permissions. A compromised external API can return poisoned data that the agent treats as ground truth.

The 2026 wave of MCP-related CVEs, including command injection and server-side request forgery classes in widely used servers, shows this is ordinary software supply-chain risk wearing new clothing. The novelty is the privilege: agent tooling usually holds live credentials, so a routine dependency compromise reaches further than it would in a normal application.

Are attackers already using agents?

Yes, and the best-documented case sets a useful baseline for how far this has gone.

In November 2025, Anthropic published an account of a cyber espionage campaign it detected in mid-September 2025 and attributed, with high confidence, to a Chinese state-sponsored group it designated GTG-1002. The operators manipulated an agentic coding tool into treating the intrusion as authorised security testing, then used MCP servers to connect it to commodity open-source penetration testing tools. Anthropic assessed that the AI executed 80 to 90 percent of tactical operations independently across roughly 30 targeted organisations in technology, finance, chemicals, and government, with human operators intervening at a handful of decision points.

Two caveats belong with that summary, and leaving them out would be dishonest. Anthropic's own report noted the AI hallucinated during operations, overstating findings and inventing results, which limited reliability. And the account rests on a single vendor's telemetry: no indicators of compromise were published, the designation is vendor-defined, and several researchers questioned how novel or large-scale the campaign really was. Confidence in the specific claims: medium. Confidence in the underlying shift: high, because the economics are not in dispute. Automation lowers the cost of targeted intrusion, and lower cost means more organisations get probed.

The defensive implication is uncomfortable. Attackers running agents operate at machine speed against defenders working at human speed, which compresses the window between first contact and material loss. That argues for continuous discovery and validated prioritisation rather than quarterly scanning cycles, whatever tooling you use to get there.

What part of agent risk is visible from the outside?

Not all of it. Anyone claiming otherwise is selling something. But a meaningful share is externally observable, which matters because external visibility is the only view you get of assets nobody told you about.

Vector	Externally visible?	How
Exposed agent endpoints and tool servers	Yes	Attack surface discovery, protocol fingerprinting, certificate and DNS data
Leaked agent credentials and API keys	Yes	Public repositories, paste sites, stealer logs, breach corpora, dark web markets
Shadow agents deployed outside governance	Often	They surface as new internet-facing assets on your domains and cloud ranges
Brand impersonation used to seed injection	Yes	Lookalike domains, fake apps, spoofed support channels feeding poisoned content to agents
Supply chain: which tools an agent calls	Partly	Public registry and repository data, not runtime composition
Prompt injection at runtime	No	Requires application-layer instrumentation and logging
Memory and context poisoning	No	Internal to the agent's memory store
Inter-agent communication abuse	No	Internal traffic

Read that table as a division of labour rather than a scoreboard. External discovery answers "what of ours is reachable, and what of ours has already leaked." Runtime controls answer "what is my agent being told to do right now." A programme that buys only one of those has a hole in it.

The practical starting point is that shadow AI behaves exactly like shadow IT before it. A team stands up an agent to solve a real problem, exposes it to make integration easier, and never registers it anywhere. It appears in no inventory and no architecture diagram. It does appear on your external attack surface, which is often the only place a security team can find it.

How do you actually secure AI agents?

Agent security borrows most of its controls from disciplines that already exist and adds a small number that are genuinely new. Sequencing matters more than tooling, so here is an order of operations that works for a team starting from nothing.

First 30 days: find out what you have.

Inventory every agent, including the ones nobody registered. Ask engineering, then verify externally, because the answers will differ.
Scan your own domains and cloud ranges for exposed agent and tool infrastructure. Check for MCP and inference endpoints bound to public interfaces, unauthenticated management consoles, and orchestration servers reachable without a login.
Enumerate the credentials each agent holds and where they live. Static keys in environment variables are the common case and the first thing to fix.
Search public code and breach sources for keys tied to that infrastructure. Assume a leaked key is being used until you can show it is not.

Days 30 to 90: constrain what agents can do.

Apply least agency and least privilege together. Cut every permission the task does not need, then cut the autonomy it does not need. An agent that drafts a payment for approval is a smaller problem than an agent that sends one.
Replace static credentials with short-lived, scoped tokens, and give each agent its own identity so audit logs can tell an agent apart from the human whose session it inherited.
Require authentication before tool enumeration on every agent-facing endpoint. Tool visibility should be an authorisation decision, not a public discovery function.
Put a human in the loop for high-impact actions: moving money, deleting data, changing access, and sending external communication. Design the approval so it shows the underlying evidence rather than the agent's summary, because ASI09 exists precisely because people approve confident-sounding output.

Days 90 and beyond: assume manipulation and test for it.

Treat every external input as untrusted, including tool output and content returned by other agents. Filter at each boundary, in and out.
Isolate the dangerous combination: an agent with access to private data, exposure to untrusted content, and the ability to communicate externally. Remove one of the three where the task allows.
Log agent decisions, not just agent outputs. You need the plan, the tool calls, and the parameters to reconstruct an incident.
Red team the agents themselves against the ASI categories, and keep monitoring the external surface continuously, because agent infrastructure changes weekly.

None of these controls stops prompt injection on its own. That is why OWASP frames the problem as layered rather than solved, and why any vendor promising a single control that eliminates injection deserves a hard question.

Where do regulators and frameworks land on this?

There is no agent-specific regulation in most markets yet, and waiting for one is a mistake, because existing obligations already apply to what agents do.

Governance frameworks give you the mapping layer. ISO/IEC 42001 covers AI management systems and is the cleanest fit for an audit-ready programme. The NIST AI Risk Management Framework, with its generative AI profile, gives a structure for risk identification that boards understand. The OWASP agentic list gives the technical threat detail underneath both.

Incident and resilience obligations apply to the consequence, not the technology. If an agent leaks personal data in India, CERT-In's six-hour incident reporting expectation is unchanged by the fact that an AI caused it. Regulated financial entities in Australia still answer to APRA CPS 234 for information asset controls, including assets managed by third parties. Singapore's MAS technology risk expectations still cover system access controls and third-party dependencies. In the EU, obligations under the AI Act phase in over several years and the timing of some requirements has been subject to amendment, so verify the current position with counsel rather than a blog post, including this one.

The practical read for a CISO: your agent programme will be judged against controls you already have on paper. The gap is usually not policy. It is that nobody applied the existing policy to a system that acts on its own.

The honest state of play

Two things are true at once, and the market usually sells one of them.

Agent-specific security tooling is young and improving quickly. Runtime guardrails, agentic red teaming, and MCP proxying are real product categories now, and for a team running dozens of agents in production they earn their budget. Best-of-breed suits large, mature teams with the headcount to run several tools well.

At the same time, the established disciplines already cover a large share of the risk today. Attack surface discovery finds the exposed endpoints. Credential exposure monitoring finds the leaked keys. Identity governance handles privilege. Supply chain review handles the tools. A smaller team gets more risk reduction, faster, by pointing those existing capabilities at agent infrastructure than by buying a specialist product it has nobody to operate.

The argument for one connected view rather than five disconnected tools is not that point tools are bad. It is that agent risk correlates across categories. An exposed endpoint plus a leaked key tied to the same infrastructure plus a lookalike domain seeding poisoned content is one attack path, and three separate consoles will show it as three unrelated tickets. Correlation is the value, and it matters most to teams without the analysts to correlate by hand.

Neither position is complete on its own, and any organisation running agents at scale will end up holding both.

Who this protects

When an agent is hijacked, the damage lands on people outside the security team's building.

The customer whose personal data an agent summarised into an attacker's request. The finance clerk who approved a payment because the agent said the vendor details had changed, and the agent sounded certain. The user who received a fraudulent message from a system they had every reason to trust, sent from a real internal address by software acting under someone else's instruction. The member of the public who stops trusting a service because it acted against them once.

Securing agents is not an abstract control objective. Software now acts on people's behalf at a scale no support desk ever could, and keeping that software from being turned against them is the whole job.

Key takeaways

Agentic AI security protects autonomous AI agents and everything those agents can act on, from the model layer down to the credentials and infrastructure.
Agents collapse the gap between a malicious input and a real action. Execution is the feature, which is why prompt injection has no single fix.
OWASP released the first Top 10 for Agentic Applications in December 2025 (ASI01 to ASI10) and introduced least agency: grant only the autonomy a task requires.
Independent scans by Trend Micro, Knostic, and Censys have repeatedly found large numbers of agent tool servers reachable on the internet without authentication.
A meaningful part of the risk is externally observable. Exposed endpoints, leaked agent keys, and impersonation used to seed injection can all be found from outside.
Start by finding the agents you did not know about, then constrain permissions and autonomy, then instrument and test. Coverage now is a first-mover advantage.

Try it against your own surface

Scrutex gives security teams the external view of their agentic attack surface. Vulnerability Insights discovers exposed agent endpoints and infrastructure on your domains and cloud ranges. Data Exposure Insights watches dark web sources, paste sites, stealer logs, and breach corpora for leaked API keys and credentials tied to those systems. Brand Insights catches the impersonation attackers use to seed poisoned content. The free tier covers core modules on your primary domains with no credit card at platform.scrutex.ai/sign-up.

FAQ

Q: What is agentic AI security? A: Agentic AI security is the practice of securing AI agents, which are systems that plan, hold memory, call tools, and take actions rather than only generating text, along with the data and systems those agents can reach. It addresses risks that appear when software acts autonomously, not just when it answers.

Q: What is the biggest risk with AI agents? A: Goal hijacking, which OWASP ranks as ASI01. An attacker plants instructions in content the agent reads, and if the agent has broad permissions and autonomy, that manipulation turns into a chain of real actions across connected systems.

Q: How is agentic AI security different from normal AI security? A: Normal AI security is concerned with what a model outputs. Agentic security is concerned with what an agent does, because agents call APIs, move data, hold credentials, and take actions, so a compromised input produces real-world effects rather than a bad answer.

Q: Can you see agentic AI risk from the outside? A: Partly. Exposed agent endpoints, tool servers, and management interfaces are discoverable through attack surface scanning, and leaked agent credentials appear in public code and on the dark web. Runtime issues such as prompt injection and memory poisoning need application-layer instrumentation.

Q: What is the OWASP Top 10 for Agentic Applications? A: It is a list of the ten most critical security risks for autonomous AI systems, released by the OWASP GenAI Security Project in December 2025 at Black Hat Europe. Risks are identified as ASI01 through ASI10 and cover goal hijacking, tool misuse, identity abuse, supply chain compromise, code execution, memory poisoning, inter-agent communication, cascading failures, human trust exploitation, and rogue agents.

Q: Are MCP servers a security risk? A: They can be, depending on how they are deployed. The protocol does not require authentication, so servers exposed to the public internet without added controls become unauthenticated endpoints that anyone can query for a tool list and often call directly. Multiple independent scans have found thousands of such servers reachable online.

Q: How do I start securing AI agents if I have no budget? A: Inventory the agents you have, including unregistered ones, then scan your own external surface for exposed agent infrastructure, cut permissions and autonomy to the minimum each task needs, replace static keys with scoped short-lived tokens, and require human approval for high-impact actions. Those steps use disciplines most teams already have.