TL;DR: AI agents can be manipulated through goal hijacking, memory poisoning, tool escalation, and recursive loops that corrupt mission context rather than code, according to Salt. The security problem is no longer prompt injection alone, but governing agent context, tool scope, and behavioural drift before legitimate access becomes malicious action.
At a glance
What this is: This is an analysis of how attackers sabotage AI agents by corrupting context, goals, memory, and tool use to turn legitimate automation into unsafe behaviour.
Why it matters: It matters because IAM and security teams now have to govern agent intent, delegated access, and runtime behaviour, not just authenticate users or protect APIs.
👉 Read Salt's analysis of context poisoning and AI agent mission hijacking
Context
AI agent security now extends beyond prompt injection to the governance of context, memory, and delegated tool use. When an agent can change behaviour at runtime, the control problem shifts from blocking malformed input to detecting when legitimate access is being redirected into unsafe or unauthorized action. That creates a direct identity and privilege question for agentic systems, because an agent with valid credentials can still behave like an internal threat.
Salt frames this as a behavioural security problem rather than a simple request filtering problem, and that distinction matters. The practical boundary is no longer only the API call, but the agent's mission briefing, memory, and approved tools. For IAM and PAM teams, that makes AI agents a form of non-human identity that needs scope, lifecycle, and runtime oversight, not just initial authentication.
Key questions
Q: What breaks when AI agents can rewrite their own mission context?
A: When mission context can be altered, access controls may still succeed while the agent pursues the wrong objective. That means normal authentication and API authorization no longer guarantee safe behaviour. Teams should look for scope drift, unusual tool selection, and task changes that indicate the agent is acting within credentials but outside intent.
Q: Why do AI agents complicate privilege governance?
A: AI agents complicate privilege governance because they can request access, use tools, and execute actions faster than human review cycles. That creates a larger attack surface for over-permissioning and misuse. Teams need continuous monitoring and strict task scoping so an agent cannot retain access beyond the approved workflow.
Q: How can security teams detect memory poisoning in agentic systems?
A: Look for persistent changes in behaviour, repeated instruction patterns that do not match approved workflows, and unexpected decisions that recur across sessions. The strongest signal is not a single bad answer, but a durable shift in how the agent prioritises tasks or selects tools. Logging the provenance of retained state is essential.
Q: What should teams do when an AI agent starts using approved tools in unsafe ways?
A: Contain the agent before it completes further chained actions, revoke or narrow its tool scope, and preserve the full sequence of calls for review. Then validate whether the problem is a poisoned instruction set, compromised memory, or an over-broad delegation model. The goal is to stop repeat execution and restore a trusted context.
Technical breakdown
Goal hijacking in AI agents
Goal hijacking is the manipulation of an agent's assigned objective so it pursues a different task while still operating through legitimate permissions. Because agents execute instructions dynamically, an attacker does not need to alter code if they can alter the context that defines what the agent is trying to achieve. The result is particularly hard to spot in API telemetry, because each call may still look authorized on its own. In identity terms, the problem is delegated authority without reliable intent assurance, which makes the agent's runtime objective part of the security boundary.
Practical implication: constrain agent task scope tightly and alert when behaviour diverges from the approved mission.
Memory poisoning and persistent behavioural drift
Memory poisoning happens when an attacker feeds false or malicious information into an agent's retained state, knowledge base, or feedback loop so future decisions are shaped by compromised context. Unlike one-off prompt injection, this is persistent and cumulative. The agent may continue to make bad decisions across many sessions, which makes the effect more like a long-lived governance failure than a single security event. For security teams, the key issue is that retained memory becomes a high-value non-human identity asset that can silently redefine how the agent acts over time.
Practical implication: treat agent memory as governed state and validate what is allowed to persist.
Tool escalation and recursive loop abuse
Tool escalation occurs when an attacker causes an agent to use approved tools in ways that exceed its intended role, or to gain access to more powerful capabilities through context manipulation. Recursive loops add another layer, because the agent may spawn sub-tasks or sub-agents repeatedly until resources are exhausted. That turns the agent into both a privilege and availability risk. The security issue is not just unauthorized API use, but the absence of runtime controls that can cap task depth, tool scope, and execution chains for autonomous systems.
Practical implication: enforce explicit tool allowlists, depth limits, and interruption controls for agent execution.
Threat narrative
Attacker objective: The attacker wants to turn a trusted AI agent into a covert internal actor that steals data, abuses APIs, or degrades operations while appearing legitimate.
- Entry occurs when an attacker injects or alters the context, instructions, or memory that an AI agent relies on to make decisions.
- Escalation follows when the corrupted context causes the agent to use legitimate credentials and approved tools for unauthorized objectives or higher-risk actions.
- Impact emerges as corporate espionage, data exposure, resource exhaustion, or chained agent activity that security controls still classify as authorized behaviour.
NHI Mgmt Group analysis
Context poisoning is the governance failure behind many agentic AI incidents. The core problem is not that agents can act, but that organisations often treat context, memory, and tool access as implementation details rather than governed assets. Once those elements become the operational source of truth, attackers can redirect legitimate behaviour without tripping traditional access controls. Practitioners should treat context integrity as a first-class control boundary.
AI agents behave like non-human identities, so IAM controls must follow delegation, not just authentication. A valid login or API credential does not guarantee safe action when the agent can reinterpret its mission or recurse through tools. That is why agent governance must combine identity, privilege, and behavioural monitoring. Security teams should expect agentic systems to require lifecycle controls closer to NHI management than to conventional application telemetry.
Tool escalation creates a new form of standing privilege in autonomous systems. When an agent can reach sensitive APIs, spawn sub-agents, or reuse broad tokens, the issue is not merely over-permissioning but unbounded execution authority. This is where least privilege must be enforced at runtime, not just at provisioning. The practical conclusion is that agent tool scope needs the same discipline that PAM brings to high-risk human access.
Recursive behaviour is an availability issue as much as an access issue. Agents that can generate nested tasks or enter loops can consume compute, trigger repeated API calls, and hide malicious intent inside apparently normal workflow expansion. That makes detection by request inspection alone inadequate. Organisations should pair behavioural baselining with execution caps and interruption mechanisms, especially where agents can chain actions across tools.
What this signals
Context integrity is becoming the control plane for agentic AI. Security teams that still focus only on prompt filtering will miss the larger failure mode, which is persistent manipulation of goals, memory, and tool scope. The programme signal is clear: agent governance now needs lifecycle controls, behavioural monitoring, and evidence of retained-state integrity, not just authentication and API telemetry.
The operating model for AI agents should increasingly resemble NHI governance with runtime guardrails. That means mapping agent identities to the tools and data they can reach, then continuously validating whether observed behaviour still matches assigned purpose. Teams that cannot evidence those relationships will struggle to explain agent actions during incident response or compliance review.
For practitioners
- Inventory every agentic access path Map each AI agent to the APIs, tools, data stores, and delegated identities it can reach. Include direct tool calls, indirect orchestration paths, and any shared service credentials so you can see where mission manipulation could become data access.
- Separate mission data from retained memory Classify prompts, goals, memory, and feedback stores as governed assets. Apply approval, retention, and integrity checks to anything that can persist beyond a single session, because poisoned memory can alter future decisions long after the original injection.
- Enforce runtime tool boundaries Use explicit allowlists, scope-limited tokens, and step controls so agents cannot invoke sensitive APIs outside their assigned role. Where possible, break high-risk actions into human-reviewed steps or time-boxed task windows.
- Baseline behavioural drift continuously Monitor sequences of API calls, task chains, and resource use rather than single requests. A legitimate agent that suddenly changes destination systems, expands task depth, or repeats calls in loops should be treated as a governance exception.
- Red-team the context layer Test how easy it is to rewrite goals, poison memory, or escalate tool use through ordinary inputs. Use those exercises to identify where agent controls depend on user trust instead of enforced policy.
Key takeaways
- AI agent attacks increasingly target context, memory, and tools rather than code.
- Agent behaviour can remain formally authorised while becoming functionally unsafe, which makes runtime governance essential.
- Security teams need NHI-style control over agent identity, delegated scope, and execution boundaries.
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 and MITRE ATLAS address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | NHI-01 | Context poisoning and tool abuse map directly to agentic application risk. |
| NIST AI RMF | GOVERN | Agent delegation and accountability are governance concerns in AI RMF. |
| MITRE ATLAS | TA0006 , Credential Access; TA0008 , Lateral Movement | The article describes abuse paths that mirror adversarial AI operations and post-access movement. |
| NIST CSF 2.0 | PR.AC-4 | Agent permissions and behavioural drift are access control issues. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege is the core control challenged by tool escalation. |
Review whether agent access remains least-privilege across tools, APIs, and data stores.
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.
- Runtime Escalation: Runtime escalation is the act of moving a task to a higher-trust or more capable model during execution. It is common in agentic systems, but it also creates a governance boundary because the escalation can change data exposure, cost, and trust assumptions within the same session.
- Context Poisoning: Context poisoning is the manipulation of information that an AI agent reads before acting. The malicious content does not need to be code. If it changes the agent’s instructions, tool choices, or assumptions, it can alter behaviour and expand the impact of a compromised delivery path.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- The specific attack patterns used to hijack agent goals, poison memory, and escalate tool use.
- The behavioural API security approach Salt describes for spotting mission drift across sequences of calls.
- The kinds of agent activity that can look authorized in logs while still being malicious in practice.
- The suggested red-teaming questions for testing whether your own agents can be manipulated.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and agentic AI identity. It helps practitioners connect delegated access, runtime behaviour, and identity control across modern security programmes.
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org