Why do prompt injection payloads that work on one agent fail on another?

Why This Matters for Security Teams

Prompt injection is not just a content-safety issue. In agentic systems, a successful payload can redirect tool use, alter task priority, or induce unintended data exposure if the agent can act on the instruction. The key risk is not whether the text appears persuasive to a human reviewer, but whether the receiving agent has enough authority, context, and reachable tools to convert the instruction into action. The OWASP OWASP Agentic AI Top 10 treats this as an application risk, not a mere prompt hygiene issue.

That is why the same payload may succeed in one environment and fail in another. One agent may have browsing, file write, or ticketing permissions; another may only summarize text or answer within a constrained workflow. Identity, authorization, and tool scope become part of the attack surface. NHI Management Group sees teams miss this distinction when they test prompts in isolation instead of testing the full action path from instruction to tool execution. In practice, many security teams encounter prompt injection only after an agent has already been given broad tool access without a matching authorization boundary.

How It Works in Practice

Whether a payload works depends on the agent’s execution chain. A prompt can be copied across systems, but the outcome changes when the target model, orchestration layer, or policy engine blocks one of three elements: the verb, the object, or the destination. A command to “send this to finance” fails if the agent cannot reach email or message tools. A request to “summarize the private repository” fails if the agent has no retrieval path. A prompt to “ignore previous instructions” fails if the agent’s guardrails treat higher-priority system instructions as non-overridable.

Operationally, defenders should map each agent to its actual capabilities, not its intended purpose. That includes tool inventory, authorization scope, session state, memory access, and any downstream systems the agent can influence. Best practice is evolving, but current guidance suggests testing prompt injection across the whole stack: model behavior, orchestration logic, retrieval pipeline, and tool permissions. A useful control set is to combine policy enforcement with least privilege and output validation, rather than relying on one layer to catch everything. NIST’s NIST AI Risk Management Framework is useful here because it forces teams to connect model risk with governance and operational controls.

• Constrain each agent to the minimum tool set needed for its task.
• Separate read, write, and external action permissions.
• Log tool calls, retrieval events, and overridden instructions for review.
• Validate sensitive actions with policy checks outside the model.
• Test against realistic payloads that include multi-step social engineering and indirect instructions.

These controls tend to break down when an agent is allowed to chain tools across loosely governed systems because the model can be safe in isolation while the workflow remains exploitable end to end.

Common Variations and Edge Cases

Tighter tool restrictions often reduce task flexibility, requiring organisations to balance agent usefulness against blast-radius reduction. That tradeoff is especially visible in workflows that need open-ended research, cross-system search, or human-like follow-up actions. There is no universal standard for this yet, so teams need to decide where dynamic autonomy is justified and where fixed workflow boundaries are safer.

Prompt injection also behaves differently across models and wrappers. One agent may reject adversarial instruction because the system prompt is stronger or the policy layer is stricter, while another may accept the same text but still fail to act because it lacks the privilege to complete the request. In agentic environments, the real issue is often not model vulnerability alone, but mismatched identity and authorization design. If an agent can impersonate a user session, reuse stale tokens, or inherit excessive NHI-style credentials, the same payload can become materially more dangerous.

For deeper threat-pattern mapping, MITRE’s MITRE ATLAS adversarial AI threat matrix helps teams separate model-level attacks from orchestration and workflow abuse. Where agent governance is still immature, the safest assumption is that a payload may fail today and succeed after a permissions change, a connector upgrade, or a new tool is added.

Related resources from NHI Mgmt Group

• What should security teams do when one agent hands work to another?
• Why do prompts that work in one model often fail in another?
• Why is prompt injection a governance problem as well as a technical one?
• How should security teams prevent prompt injection in AI agent workflows?