Agentic AI security beyond prompt injection: six missed threats

At a glance

What this is: This is an Akto analysis of six AI agent threat patterns, with the key finding that prompt injection is only one part of a broader runtime risk surface.

Why it matters: It matters because IAM, PAM, and security teams must govern agent identity, tool access, memory, and autonomy together rather than treating AI threats as a filter problem.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).

👉 Read Akto's analysis of six AI agent threats beyond prompt injection

Context

AI agent security is broader than prompt injection because agents do not just generate text, they make decisions, call tools, retain memory, and interact with other systems. That turns the primary problem into governance of runtime behaviour, not just filtering malicious input.

For IAM and NHI programmes, the hard part is that an agent can inherit tool permissions, write to memory, and pass trust through agent-to-agent workflows. Traditional application controls assume fixed code paths and predictable action boundaries, which no longer holds when the actor is an AI agent.

That makes AI agent identity, access scope, and decision boundaries part of the same control plane. The article is typical of the current market conversation: teams are recognising the problem, but many still underestimate how quickly runtime agency expands the attack surface.

Key questions

Q: How should security teams govern AI agents that can choose tools at runtime?

A: Security teams should govern runtime agent choice as an access event, not as a simple application action. That means scoping permissions to the task, limiting token lifetime, logging every tool decision, and blocking the agent from reaching systems outside its approved context. Static roles alone are not enough when the execution path changes on each run.

Q: Why do AI agents create more risk than traditional automation?

A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously. Traditional automation follows fixed rules, but an agent can be manipulated into using its own authority in unintended ways. That makes permission scope, tool boundaries, and monitoring more important than model accuracy alone.

Q: What do security teams get wrong about prompt engineering for AI agents?

A: They often assume better wording is enough to create reliable control. In practice, prompt style can help, but it does not create a secure boundary when the agent is still free to reinterpret context. Real governance comes from structure, validation, and constrained action paths.

Q: When should organisations require human approval for an AI agent action?

A: Require human approval when the action could change infrastructure, expose sensitive data, move laterally across systems, or trigger a business-critical workflow that is hard to reverse. Approval is also warranted when the agent’s decision depends on ambiguous input or external data that cannot be trusted at face value. High-consequence actions need a human stop point.

Technical breakdown

Why AI agents create a different attack surface

An AI agent is not just a model. It is a system that can observe context, choose actions, invoke tools, and update state over time. That matters because security controls built for static software assume a fixed code path and a stable set of inputs. Once the agent can decide, the attack surface grows with every new tool, memory store, and downstream integration. The core technical issue is that the agent inherits real permissions and can use them in combinations the original designers did not expect.

Practical implication: model the agent as a runtime identity with explicit boundaries, not as a chat interface with a security wrapper.

Tool abuse, trust boundaries, and MCP exposure

Tool abuse happens when an agent has more capability than it needs, especially through tools exposed over protocols such as MCP. The risk is not only single-tool misuse. It is the sequence: read, transform, act, and exfiltrate can all look legitimate in isolation while forming a harmful chain in combination. Agent-to-agent interactions add another layer of trust propagation, because one agent's output becomes another agent's input. If those boundaries are not verified, the system accepts hostile instructions as cooperative work.

Practical implication: scope tools at the smallest viable level and inspect sequences of tool calls, not just individual calls.

Memory poisoning and excessive autonomy in AI agent security

Memory poisoning turns stored context into a persistence layer for attacker influence. If the agent treats retrieved content, learned preferences, or shared memory as trusted without provenance checks, the false state keeps shaping future decisions. Excessive autonomy compounds this, because an agent with broad execution latitude can carry a poisoned objective into real-world actions before any human review occurs. The security failure is not only input compromise. It is the combination of retained state and approval-free action.

Practical implication: treat memory writes and high-impact actions as governed assets with provenance, rollback, and human approval thresholds.

Threat narrative

Attacker objective: The attacker wants to steer an AI agent into taking harmful actions while appearing to operate normally, so the abuse blends into legitimate automation.

1. Entry occurs when an attacker plants malicious instructions in content, memory, or an agent-visible workflow that the agent treats as trusted context. Escalation happens when the agent uses inherited tool permissions or shared memory to amplify the malicious instruction into real action. Impact follows when the agent performs unauthorized refunds, data sharing, credential exposure, or cross-agent propagation at runtime.

Breaches seen in the wild

• Gemini AI Breach — Google Calendar Prompt Injection — Gemini AI assistant prompt injection attack leaks sensitive Google Calendar data.
• Amazon Q AI Coding Agent Compromised — Amazon Q AI coding agent compromised via prompt injection enabling hackers to inject data-wiping commands.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent security is now an identity problem, not just an application security problem. Once a system can call tools, retain memory, and act without a human in the loop for every step, the control questions move into IAM, PAM, and lifecycle governance. The practical conclusion is that agent identity, tool scope, and action approval must be managed together, not as separate security projects.

Goal hijacking is the clearest proof that input trust and action trust are no longer the same thing. An attacker can shape what the agent reads without touching the code, then steer the agent toward the attacker’s objective while the system appears to behave normally. That breaks the old assumption that controlling the prompt or input channel is enough to control the outcome. Practitioners should treat trusted input and trusted intent as distinct governance domains.

Memory poisoning creates identity persistence in the wrong place. If a retrieved note, knowledge-base record, or shared memory entry can alter future decisions, then the attacker has achieved durable influence without needing repeated access. This is not simply data contamination. It is a long-lived trust primitive inside the agent’s decision loop, and that changes how provenance, rollback, and review must be thought about.

Tool abuse turns over-provisioned agent access into a compound control failure. The problem is not only broad permissions, but the way individually safe calls become unsafe when chained. That is why least privilege for agents has to be tool-level and sequence-aware, with explicit monitoring of call order and downstream effects. The practitioner conclusion is straightforward: if the chain is not governed, the permission model is not finished.

Excessive autonomy collapses the assumption that a human operator remains the accountable decision point. That assumption was designed for human-paced review and intervention. It fails when an agent can choose actions, select tools, and execute immediately without approval gates. The implication is not simply to add more checks; it is to recognise that existing access review and approval cadences may no longer see the relevant risk window at all.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to the AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing credentials.
• For a broader control lens, see OWASP NHI Top 10 for agentic application risk patterns and governance implications.

What this signals

Goal hijacking creates a new governance gap: teams can no longer assume that controlling prompts or inputs controls outcomes. The programme implication is that agent runtime behaviour needs its own monitoring, escalation thresholds, and review model, especially where tool calls can trigger business actions.

With 80% of organisations already reporting AI agents acting beyond intended scope, the issue is no longer theoretical. That scale suggests governance programmes should prioritise agent identity, tool scoping, and approval boundaries before expanding deployments further.

The next stage of maturity is to connect agent identity controls with broader identity governance and access review processes. The 52 NHI Breaches Report remains the most useful reference point for understanding how identity trust failures become operational incidents.

For practitioners

• Define the agent as a governed identity Assign each agent a unique identity, map its ownership, and document which systems it may call. Do not let agent credentials blend into shared service accounts or generic automation identities.
• Scope tools at the lowest viable privilege Review every tool an agent can touch and remove anything not required for the specific workflow. Apply least privilege at the tool level, not just at the user or workload level, and revalidate after each workflow change.
• Protect memory as a security boundary Treat long-term memory, retrieval stores, and knowledge bases as governed write targets. Add provenance, validation before write, and rollback for poisoned entries that can influence later decisions.
• Set approval gates for high-impact actions Require human approval for refunds, record deletion, external sharing, or other irreversible actions. Keep those gates outside the model so the agent cannot bypass them through prompt manipulation.
• Monitor tool-call sequences and agent-to-agent traffic Look for unusual call chains, repeated boundary crossings, and suspicious handoffs between agents. Sequence-level telemetry is necessary because individual actions may look normal while the overall chain is malicious.

Key takeaways

• AI agent risk is broader than prompt injection because the real issue is what agents can do at runtime.
• Tool access, memory, identity, and autonomy form one governance problem, not four separate ones.
• Security teams need approval gates, sequence monitoring, and governed memory to keep agent behaviour inside policy.

Key terms

• Goal hijack: A failure mode where an agent is steered away from its approved objective and begins pursuing a different one, often through manipulated inputs or chained context. For autonomous or semi-autonomous systems, the risk is not only misuse of a tool but the redefinition of the mission itself.
• 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.
• Tool Abuse: Tool abuse occurs when an AI assistant is manipulated into making actions through connected APIs, plugins, or workflows that the user did not intend. The risk is not only incorrect output, but execution of legitimate systems with attacker-chosen inputs or destinations.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.

What's in the full article

Akto's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples of goal hijacking, memory poisoning, and tool abuse in agent workflows
• Detailed defensive measures for agent identity, trust boundaries, and approval gating
• Practical guidance on monitoring agent-to-agent traffic and sequence-level anomalies
• Operational examples of how over-provisioned tools become attack chains in production

👉 Akto's full post covers the threat mechanics, defensive measures, and agentic attack examples in more detail.

Deepen your knowledge

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