A tool-call hijack is a manipulation of the action a model sends to an external system after the model has already appeared to decide correctly. In agentic environments, the danger is that the visible response remains normal while the executed request is silently redirected or altered.
Expanded Definition
Tool-call hijack is a post-decision manipulation of an agent’s execution path, where the model appears to select a legitimate action but the request sent to the external system is changed before it is executed. In agentic AI, this matters because the response visible to users can remain plausible while the underlying tool invocation is redirected, parameterised differently, or wrapped with extra instructions. That makes it distinct from prompt injection, which targets the model’s reasoning, and from ordinary API abuse, which does not depend on altering an agent’s chosen tool action.
Definitions vary across vendors, but the security concern is consistent: the trust boundary between model output and tool execution is weak. In practice, the issue often sits in orchestration layers, middleware, browser automation, function-calling adapters, or message buses that transform tool arguments after the model produces them. Guidance in the NIST Cybersecurity Framework 2.0 is relevant here because integrity and controlled execution are central to preventing silent modification of privileged actions. The most common misapplication is assuming that a correct model answer guarantees a correct tool action, which occurs when teams inspect only the LLM output and not the final request payload.
Examples and Use Cases
Implementing tool-call controls rigorously often introduces latency and complexity, requiring organisations to weigh safer execution against faster autonomous workflows.
- An agent prepares a ticketing-system update, but a compromised middleware layer rewrites the target ticket ID so the change lands in the wrong incident record.
- A support agent generates a password reset request, but the function-call adapter swaps the account identifier and resets credentials for a higher-value service account instead.
- A browser-based agent appears to submit an approved purchase order, while a DOM manipulation step alters the recipient before the form is posted.
- An internal workflow parses the model’s JSON output, then a downstream transformation injects an extra tool parameter that broadens scope beyond the original intent.
- As described in Ultimate Guide to NHIs, many organisations still store secrets outside protected managers, which makes hijacked tool calls more dangerous when the resulting credentials are widely reusable.
For design and verification patterns, teams often compare agent controls with the NIST Cybersecurity Framework 2.0 to ensure that tool invocation remains traceable, authorised, and tamper-evident. The same logic applies whether the tool is an API, a shell action, or an administrative console.
Why It Matters in NHI Security
Tool-call hijack is especially dangerous in NHI environments because service accounts, API keys, and workload credentials often have broad machine-to-machine reach. When an agent can act on behalf of a Non-Human Identity, a subtle change to the executed request can turn a routine automation into unauthorised data access, privilege escalation, or destructive change. NHI Management Group reports that 97% of NHIs carry excessive privileges and only 5.7% of organisations have full visibility into their service accounts, which means a hijacked tool call frequently lands inside an already over-permissioned trust zone. That combination makes the blast radius much larger than the model prompt alone suggests.
This is also why tool-call integrity must be treated as part of identity governance, not just application security. If requests can be altered after policy checks, then approval workflows, logging, and least-privilege boundaries no longer provide the protection teams assume they do. Ultimate Guide to NHIs provides the broader governance context for why visibility, rotation, and offboarding matter when machine identities execute autonomous actions. Organisations typically encounter the impact only after a failed audit, a fraudulent transaction, or an unexpected production change, at which point tool-call hijack becomes operationally unavoidable to address.
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 OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Covers agent-tool abuse where model intent diverges from executed actions. | |
| OWASP Non-Human Identity Top 10 | NHI-07 | Tool hijack often exploits privileged NHI actions and weak execution controls. |
| NIST CSF 2.0 | PR.AA | Identity and access governance applies to autonomous tool execution paths. |
Apply authentication, authorization, and integrity checks to every agent tool action.
