AI agent security depends on five attack boundaries, not prompts

At a glance

What this is: This is a practitioner guide to AI agent security that frames agents as systems with five distinct attack surfaces and shows why prompt-only defenses miss the real risk.

Why it matters: It matters because IAM, PAM and security teams now need to govern agent goals, tool access, memory, credentials and message flows as runtime control points, not as static application settings.

By the numbers:

• By the end of 2026, Gartner predicts 40% of all enterprise applications shipped will have task-specific agents baked in, compared to less than 5% in 2025.
• Unit 42 observed 22 unique payload variations in indirect prompt injection attacks hidden on live websites.
• NIST’s AgentDojo testing found unknown attacks succeeded 81% of the time compared to 11% for known attacks.
• Mindgard says a single payload accounted for 75.8% of injected pages analysed in one telemetry set.

Context

AI agent security is the practice of controlling what an autonomous or semi-autonomous system can decide, touch and transmit at runtime. The key governance gap is that agents do work, so a successful manipulation becomes an action rather than a bad output, which makes identity and access decisions part of the attack surface from the start.

Traditional application security models assume a bounded user session and a stable request path. Agents break that assumption because they can plan, call tools, reuse memory and pass credentials across systems, which means the control problem shifts from text moderation to action authorization.

Least privilege for AI agents becomes the baseline question here, because an agent that can read, write, send, pay or execute beyond task scope has a blast radius that grows with every tool and trust decision.

Key questions

Q: What breaks when organisations rely only on prompt filtering to secure AI agents?

A: Prompt filtering can reduce obvious abuse, but it does not stop a compromised agent that has already accepted malicious instructions or been manipulated through its environment. In practice, the attacker may pivot through tools, files, APIs, and connected systems after the prompt stage. Defenders need visibility into runtime behaviour, not just text exchanges.

Q: Why do over-privileged AI agents create higher business risk than ordinary users?

A: Over-privileged agents can execute many more actions than the task actually requires, so one bad decision can cascade into wrong approvals, refunds, data movement, or API calls. The risk is not just misuse. It is that the agent can act quickly, repeatedly, and without the human timing constraints that limit user mistakes.

Q: What are the signs that AI agent security controls are too weak?

A: Common warning signs include agents accessing systems or data outside their intended scope, sharing sensitive information inappropriately, and using credentials or tools without clear justification. Another indicator is inconsistent visibility into what the agent touched, especially when security, compliance, and legal teams do not share the same view of agent activity and data access.

Q: How should organisations implement NIS-2 controls across identity and access management?

A: Start with enforceable identity ownership, least privilege and auditable lifecycle controls for every regulated system. Then prove that approval, access use and revocation are captured in a form supervisors can inspect without reconstruction. If access cannot be traced end to end, the control design is not ready for a compliance regime that now expects operational evidence.

Technical breakdown

Why AI agents have five trust boundaries

An LLM application mostly exposes one boundary, the prompt. An AI agent exposes goals, tools, memory, identity and inter-agent communications, and each boundary can be subverted in a different way. Goal hijack changes what the agent is trying to do. Tool abuse changes what it can invoke. Memory poisoning persists across sessions. Identity abuse turns access into action. Insecure inter-agent communication lets one compromised component influence the rest of the system. The important architectural point is that the model itself is not the control plane; the runtime permissions around it are. Security needs to treat each boundary as separately governable. See the Agentic AI Security Guide.

Practical implication: Model each boundary as a separate control domain and test them independently before deployment.

How prompt injection becomes tool misuse

Indirect prompt injection works because the agent reads untrusted content as if it were instruction material. Once the agent accepts attacker-authored guidance from a website, document, ticket or page comment, the next step is usually tool misuse: sending an email, reading a file, making a payment or issuing a command the attacker wanted. Tool descriptions and metadata are themselves part of the attack surface when the agent treats them as trusted context. That is why the weakness is not just input filtering. It is the combination of instruction following plus broad tool reach plus weak policy at execution time.

Practical implication: Bind every tool call to policy at execution time, not at prompt ingestion time.

Why persistent memory and shared credentials expand blast radius

Persistent memory turns a one-time compromise into a standing influence problem. If an attacker can seed a false fact or standing instruction, the agent may carry it into later sessions without any visible malicious input present. Shared credentials create a parallel problem, because a single OAuth token, service account or delegated user credential can give the agent more authority than the task requires. In multi-agent systems, this gets worse when credentials and trust are inherited across components. The mechanism is simple: durable state plus durable privilege equals durable compromise, even when the original prompt injection is gone. See the Agentic AI Identity Guide.

Practical implication: Separate memory trust from credential trust and scope each to the minimum task boundary.

Threat narrative

Attacker objective: The attacker wants the agent to perform legitimate-looking actions on their behalf so that data, commands or transactions are executed under the agent’s authority.

1. Entry begins when an attacker plants indirect prompt injection, poisoned tool metadata or malicious instructions in content the agent will later read.
2. Escalation follows when the agent accepts the injected content as guidance and uses its existing tools, memory or credentials to perform attacker-directed actions.
3. Impact occurs when those actions propagate into email, code, file systems, payments or agent-to-agent workflows, turning a single prompt into a real-world exploit.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Five boundary security is the right mental model for AI agents: prompt-only defense is already obsolete because the real compromise path runs through goals, tools, memory, identity and inter-agent communication. Each boundary creates a different trust failure, so the governance model has to be runtime-native rather than text-native. Practitioners should stop asking whether the prompt is safe and start asking which boundary is currently unconstrained.

Least privilege for AI agents is not a static provisioning problem: the useful control is not just reducing permissions, but binding each permission to a task, action and trust decision at execution time. When agents can plan, select tools and hand off work to other agents, standing privilege becomes a pathway to autonomous overreach. The implication is that identity governance now needs action-scoped authority, not just account-scoped entitlements.

Identity and privilege abuse is the decisive failure mode once an agent is compromised: Mindgard’s analysis makes clear that the exploit does not end at injection. It ends when an over-credentialed agent can turn manipulated intent into real actions, which is why identity is the last and most important containment layer. The practical conclusion is that agent security and NHI governance are now the same control problem at different runtime speeds.

Tool metadata is a governance object, not a developer convenience: poisoned descriptions, rug pulls and shadowing work because the agent trusts what it reads about tools as much as the tool itself. That creates a new class of supply-chain-style identity risk around capability registration, approval and mutation. Security teams should treat tool definitions, not just tool endpoints, as governed assets.

Runtime protection must sit between intent and action: once an agent has authority to act, detection after the fact is too late for many workflows. The posture shift is from watching what the model says to controlling what the system is allowed to do at the moment it does it. That is the point where agentic security becomes operational identity security.

From our research library:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Authorisation Guide

What this signals

AI agents are moving from experimental assistants into production operators, which means the security programme has to shift from preventing bad text to preventing unauthorised action. The control point is no longer only the model prompt; it is the authorisation boundary for every tool, credential and delegated decision.

Identity blast radius: the practical risk metric for agents is how far one manipulated task can travel through tools, memory and shared credentials before the system notices. When that blast radius is not bounded, agent security becomes a runtime governance problem rather than a testing exercise.

Governance teams should expect agent identity to converge with broader NHI controls, because the same questions now apply to service accounts, workflow bots and autonomous assistants: who owns them, what can they do, and when do they lose access?

For practitioners

• Implement boundary-specific red teaming Test goals, tools, memory, credentials and inter-agent messages separately so you can see which boundary fails first and which one cascades into real action. Read Red Teaming AI Agents for Identity Abuse.
• Scope every agent to task-level authority Replace broad shared credentials with task-scoped permissions, and verify that the agent cannot reach tools or data outside the specific work item.
• Validate tool metadata before approval Review tool descriptions, registration records and mutation paths as governed inputs, because poisoned metadata can drive agent behaviour without changing the endpoint itself.
• Add runtime policy gates on action execution Enforce policy when the agent tries to send, write, pay or execute, not just when it reads content, so manipulated prompts cannot become automatic actions.
• Instrument cross-session memory and credential reuse Track when saved memory or cached trust decisions survive into later sessions, and treat that persistence as a control event rather than a convenience feature.

Key takeaways

• AI agents expand the attack surface beyond prompts into goals, tools, memory, identity and message flows, so security has to move to runtime control.
• The article links real-world attack patterns to this model, including indirect prompt injection, tool poisoning, persistence and privilege abuse.
• Practitioners need task-scoped authority, governed tool metadata and execution-time policy enforcement if they want to constrain agent blast radius.

Related NHI Mgmt Group resources: Agentic AI Security Guide · AI Agent Authorisation Guide · Agentic AI Identity Guide · AI Agent Observability, Audit and Incident Response Guide

Key terms

• AI Agent Security Risk Review: An AI agent security risk review is an internal assessment that tests what a deployed agent can actually be made to do, who owns it, and whether its behavior fits bank risk policy. It goes beyond documentation to examine live tool use, data access, and governance accountability before or after deployment.
• Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.
• Memory Poisoning (ASI06): An attack where malicious content is injected into an AI agent's memory or context, causing it to alter its behaviour in subsequent tasks, potentially exfiltrating secrets, escalating privileges, or acting against its intended purpose.
• Agent Blast Radius: Agent blast radius is the amount of damage an AI agent can cause if it is compromised, misconfigured, or behaves unexpectedly. It includes the systems, data, identities, and actions the agent can reach through its permissions, tool access, and network paths, and is reduced by least privilege, segmentation, and strong controls.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.