TL;DR: Prompt injection is only one of six AI agent threats highlighted by Akto, including goal hijacking, memory poisoning, tool abuse, weak agent identity, multi-agent cascades, and excessive autonomy. The central shift is that agents act, remember, call tools, and trust other agents, so input filtering alone cannot contain runtime abuse.
At a glance
What this is: Akto argues that prompt injection is only one slice of the AI agent threat surface, with runtime actions, memory, tools, and inter-agent trust creating additional exposure.
Why it matters: IAM, PAM, and NHI teams need to treat agent identity, tool privilege, memory provenance, and autonomy limits as control points, not just model input filters.
Context
Agentic AI changes the security problem because the system does more than generate text. It can take actions, retain memory, call external tools, and exchange outputs with other agents, which means the attack surface expands from prompt content to runtime behaviour and delegated capability.
That shift matters for identity governance because the security question is no longer only what the model saw. It is which agent acted, what it was allowed to do, what memory it trusted, and whether downstream systems treated its output as authoritative.
For practitioners, the key problem is that controls built around static requests and fixed code paths do not fully cover agents that make decisions mid-session. Once the actor can choose actions, the governance model has to account for trust, privilege, and persistence as separate failure modes.
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 overprovisioned AI agents create outsized security risk in enterprise environments?
A: Overprovisioned AI agents create risk because they can reach systems and data beyond the task they were meant to perform. Once access is broader than necessary, a compromised prompt, model error, or malicious instruction can trigger unauthorized actions, data exposure, or credential leakage. Least privilege matters for agents just as it does for users, but the blast radius can be much larger because agents act quickly and at scale.
Q: How do you know if agent identity controls are actually working?
A: Look for whether you can reconstruct a complete path from trigger to identity to permission to action. If you cannot answer who invoked the agent, what access was active, and which systems it touched, then your controls are only documenting assignment, not governing execution. Good controls produce evidence, not assumptions.
Q: What should organisations do when an AI agent can initiate work on its own?
A: Treat the agent as a governed identity with runtime controls, not as a passive application feature. Require traceable ownership, scoped credentials, containment paths, and a clear escalation rule for high-consequence actions so self-initiated activity stays inside documented boundaries.
Technical breakdown
Why prompt injection is only one agentic AI threat
Prompt injection targets the text an agent reads, but agentic systems expose a wider runtime surface. Once an LLM can plan, call tools, store memory, and interact with other systems, the attacker does not need to change code to change outcomes. They can steer the decision loop through data the agent already trusts. That is why the security problem moves from input sanitisation to controlling what the agent can do, remember, and delegate. In practice, the same prompt may produce different actions because the context, memory, and available tools change over time.
Practical implication: Treat prompt filtering as one control layer, not the security boundary for agent behaviour.
How tool abuse emerges through over-provisioned agent permissions
Tool abuse happens when an agent inherits more capability than the task requires. In the article's model, that can include refunding, deleting records, querying unrelated databases, or chaining otherwise safe tools into a harmful sequence. The failure is not the existence of tools, but the lack of authorization at the tool level and the assumption that a human is always driving the action. When an attacker shapes the agent's goal, the agent will use every permitted capability to satisfy that goal. That creates a privilege problem, not just a content problem.
Practical implication: Review agent tool scope continuously and remove any action the agent does not absolutely need.
Why weak agent identity and multi-agent trust are control failures
Agentic systems often run on behalf of users, spawn sub-agents, and exchange outputs across trust boundaries. If agent identity is weak, downstream systems cannot prove which agent performed which action, and if one agent's output is blindly trusted, compromise can cascade through the chain. The article's multi-agent examples show that cooperation becomes a liability when each hop treats the previous hop as trusted by default. That means identity, provenance, and inter-agent verification become governance controls, not implementation details.
Practical implication: Verify agent identity and re-check inter-agent messages at every trust boundary.
NHI Mgmt Group analysis
Prompt injection is a narrow symptom of a wider runtime governance problem: the more important question is not what the agent read, but what it was able to do after reading it. Once an AI system can act, store memory, and call tools, the control surface moves outside the model and into delegated runtime behaviour. Practitioners should stop treating prompt safety as the primary security boundary.
Identity for agents is now a provenance problem, not just an authentication problem: the article shows that agents can run on behalf of users, spawn sub-agents, and operate continuously without a human present. That makes weak agent identity a downstream control killer because the organisation loses the ability to attribute actions, validate trust, and separate legitimate automation from hostile impersonation. The practitioner implication is that agent identity must be as explicit as workload identity.
Tool privilege and trust chaining create identity blast radius: one over-provisioned agent can be pushed into actions that would never be allowed if a human were clearly in the loop, and one compromised agent can contaminate the next. This is where least privilege, provenance, and boundary checks intersect. The real issue is not a single bad action, but how far that action can propagate through tools, memory, and peers.
Excessive autonomy collapses the assumption that review happens before impact: access review processes were designed for actors whose privileges persist long enough to be examined. That assumption fails when an agent can decide and act in a single runtime session, because the harmful sequence can complete before any review cycle begins. The implication is that governance has to move from after-the-fact certification to pre-execution control of high-impact actions.
Agentic AI identity governance is becoming a core discipline alongside NHI control: the same structural problems that affect service accounts appear in more dynamic form when the actor is an AI agent. The difference is that context changes, memory persists, and trust is delegated at machine speed. Practitioners should expect agent identity, memory provenance, and tool authorization to converge into one governance surface.
From our research library:
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Identity Maturity Model
What this signals
Excessive autonomy changes the timing of governance: access review assumes an identity persists long enough to be certified, but agentic systems can complete a risky sequence before a review cycle ever sees it. That pushes control design toward issuance-time checks, scoped approvals, and runtime monitoring rather than retrospective certification.
Agentic AI governance now overlaps with NHI governance in practical ways: the same questions that matter for service accounts also matter for agents, including privilege scope, memory integrity, and offboarding of access paths. The difference is that the agent can adapt its sequence mid-session, which makes static control baselines less reliable.
Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey. That gap suggests practitioners should expect governance pressure to rise faster than their current identity models can absorb.
For practitioners
- Harden agent identity and provenance Assign each agent a verifiable identity, log every action it takes, and require provenance on tools, memory writes, and downstream agent messages so you can attribute behaviour precisely.
- Limit tool scope to the minimum task set Remove any tool, database, or action path the agent does not absolutely need, then re-audit the remaining permissions after each workflow change.
- Separate trusted instructions from untrusted context Treat retrieved text, tickets, documents, and other agent inputs as hostile data until the system confirms they are not being promoted into commands.
- Control memory writes and rollback poisoned state Allow only validated writes into long-term memory, tag entries with provenance, and keep rollback capability for contaminated facts or preferences.
- Set approval gates for high-impact actions Require explicit human approval for actions that move money, change records, or trigger external communications beyond the defined risk threshold.
Key takeaways
- The article frames agentic AI as a runtime security problem, not a prompt-only problem, because agents can act, remember, and coordinate with other systems.
- The six threat areas it highlights are goal hijacking, memory poisoning, tool abuse, weak agent identity, multi-agent cascades, and excessive autonomy.
- Practitioners need controls that govern agent identity, tool scope, memory provenance, and approval thresholds before the agent reaches an irreversible action.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI01 — Agent Goal Hijack | The article's goal hijacking section maps directly to attacker-driven redirection of agent objectives. |
| ASI02 — Tool Misuse | Tool abuse is a central theme because the article focuses on agents using legitimate tools harmfully. | |
| ASI03 — Identity & Privilege Abuse | Weak agent identity and over-provisioned access are explicit risk areas in the source article. | |
| Recommendation — Map goal-hijacking scenarios to ASI01 and constrain objective changes with policy checks before execution. Apply ASI02 to audit tool scope and block agents from chaining benign tools into harmful sequences. Use ASI03 to verify agent identity and limit privileges to the minimum needed for each workflow. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Over-provisioned agent permissions mirror classic non-human identity privilege creep. |
| Recommendation — Apply NHI-05 to reduce agent permissions to the smallest viable tool and data set. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is fundamentally about governing agent behaviour, trust, and accountability. |
| Recommendation — Establish AI governance controls that define ownership, approval thresholds, and accountability for agent actions. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Agent compromise is used to reach tools, data, and downstream systems through trusted paths. |
| Recommendation — Map agent abuse to credential access and lateral movement patterns to improve detection coverage. | ||
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.
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 IAM or NHI governance programme, it is worth exploring.
Published by the NHIMG editorial team on August 1, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org